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....”
And later:
“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?
Is this a more extreme manifestation of the alignment trap that you keep going on about? It would make sense that an IT operation that tries slavishly to align itself to the business's objectives, when the business has a pathological organisation, would contribute to the poor economic performance of that organisation.
ReplyDeleteIncidentally, the originator of the observation that "any piece of software reflects the organizational structure that produced it" was probably Fred Brooks, talking about the IBM System 360 operating system architecture.
This comment has been removed by a blog administrator.
ReplyDeleteMany institutions limit access to their online information. Making this information available will be an asset to all.
ReplyDeleteAllan,
ReplyDeleteI heard a talk recently where Vodafone and HP applied Conway in reverse - re-organised the team structures - precisely in order to achieve the software architecture they knew they needed:
http://www.servicetechsymposium.com/agenda2012.php#conways_law_and_serviceorientation
The slides are here (see page 7): http://www.servicetechsymposium.com/dl/presentations/conways_law_and_serviceorientation.pdf
I think we'll see more and more of this approach which you identified here (back in 2009).
Matthew
The slides are now at http://www.servicetechsymposium.com/2012/dl/presentations/conways_law_and_serviceorientation.pdf
DeleteThanks Matthew - a really big thanks for remembering after all this time.
ReplyDeleteSlides look interesting although I have to admit without the commentary its not completely clear what they are talking about.
The conclusion is perhaps the most interesting part, the first bullet says:
"Find communication issues to fix business issues, then align technology - In order to fix technology spaghetti, fix business spaghetti first."
That sounds right to me, I think business often sees technology as a silver hammer which can fix a problem but do often you need to fix the business first and then apply technology.
But, I have two caveats about the presentation: it starts to sound like Business Process Re-engineering "Vodafone has a mess, consultants from HP understand and then impose the solution" which is supported by second caveat in the conclusions they say "Force a new communication structure". Classic BPR language - well actually, slightly toned down from classic 90's BPR warfare.
Still, back on topic: what this does show is that an appreciation of Conways Law can be useful. Second, as I've speculated before, Conway's Law is symmetrical
in that it can run backwards. Well, actually, Conway's Law is a manifestation of the homomorphic force which works to preserve the status quo in both directions.