Regular readers of this blog will know I have a thing about Conway’s Law. In my mind it makes sense and it links what I did before (software coding and architecture) with what I do now (organization and process improvement). My logic is: If Conway’s Law holds then architecting software starts with the organization.
So it was with interest I ran across a working paper from Harvard Business School entitled “Exploring the Duality of Product and Organizational Architectures: A Test of the Mirroring Hypothesis” (Alan D. MacCormack, John Rusnak, and Carliss Y. Baldwin). The author’s note Conway’s Law as one example of the mirroring hypotheses and cite several others too - which adds to the evidnece that there is something here.
(The link above is to a March 2008 version of the paper, the one I downloaded a couple of months ago was version 3.0 and dated October 2008, I’ve no idea what, if anything, changed in that time or where the October version is for download.)
In this paper the authors try and show statistically that organizational form does effect software architecture. Most of the paper’s 33 pages lays out in detail how they did this, and you could, if you so wish, poke holes in their techniques and question whether the analysis holds up.
Disclaimer, as is my usual practice I’ve read the introduction, the closing discussion and some of the material in between. Life is too short to read 33 pages of academic prose but it could be I’ve missed something, please let me know if I have.
That said, if you are willing to accept their hypothesis and method. There are two minor points that give me concern: 1) all the code they look at is Open Source, 2) we know little about the development practices employed by these teams. Both facts could skew the results, still I’m willing to give them a broad acceptance - then they show the hypothesis stands up.
The authors say:
“Our results reveal significant differences in modulality, consistent with a view that larger, more distributed teams tend to develop products with more modular architectures. Futhermore the differences are substantial - the pairs we examine vary by a factor of eight....”
“our study provides evidence to support the hypothesis that a product’s architecture tends to mirror the structure of the organization within which it is developed.”
There are many implications of this work and several are discussed by the authors. For me a few things come immediately to mind:
• The work of the architect and the manager are more difficult to separate than is commonly assumed. The organization will always effect the architectural.
• If you want a highly modular system distribute your team.
• This is why broken organizations usually have broken architectures too.
• When fixing a broken organization and/or architecture: fix the organization first.
This paper in common with most other work on Conway’s Law emphasises the way the architecture mirrors the organization. In so much as thisis true and it happens at first, organization determines architecture.
I also believe the reverse can be true. The organization can come to copy the architecture. In a world increasingly dominated by existing “legacy” systems it is common to see development organizations split up to model the software.
For example: Front End (UI) team, Business Logic Team and a Database team corresponding to three layers in a software. This may lead to a modular design in time but it complicates co-ordination. It becomes more difficult to make changes to the code and change the organization.
While most of the software world (including myself when I code) cling to the layered model it goes against object-oriention. In OO the object is should be self contained, too much layering and the object model breaks down. Layering is procedural not OO. The same thing happens in organizations. But all that will need to wait for another blog entry.
More on Conway’s Law:
• What do we think of Conway’s Law now? (EuroPLoP 2005 focus group)
• 2006 Blog posting: Return to Conway’s Law
• The original paper from 1968: How do committee invent?