Conway's Law v. Software Architecture
There are times when I wonder if there is any point to the discipline called "Software Architecture." Sure design can make a difference in the small but when it comes to the big then, for my money, Conway's Law is a far more powerful force than the plans, designs and mandates of an enterprise architect.
Conway's Law predates Agile and Waterfall but it applies to both:
"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure." Conway, 1968
The original paper “How do committees invent?” is available from Conway’s own website. The original publication was in Datamation, April 1968.
While Conway's Law can be seen at the macro level, the company level, it is also observed in in the small, at the micro level. The law if often restated in the small as:
"If you have four developers writing a compiler you will get a four pass compiler"
"If you have three developers writing a UI you will get three ways of doing everything (mouse click, menu item, short-cut key)
It is a little like a children's cartoon where the superheroes need to rescue somebody: Superman says "I can use my super strength to lift the ice boulders out of the way", while Fireman says "I can use my fire breath to melt the ice" and Drillerman says "I use my drill hands to make a rescue tunnel". Once added to the picture each specialist finds a way to utilize his or her special powers. For a software team this can lead to poor architecture, over complicated designs and competing modules.
In setting up a team architectural decisions are being made even if no architecture diagrams are being drawn. Just deciding to staff the team with four developers rather than three will influence the architecture because work now needs to be found for the fourth team member.
These decisions are made at the time when the least information is known - right at the beginning. They may made by planners - project managers - who have little knowledge of the technologies or by people who will not actually be involved in the development effort, e.g. enterprise architects.
To avoid this my advice is to start a team as small as possible. Try to avoid making architectural decisions in staffing the team by understaffing it. Keeping the team hungry will reduce the possibility of building more than is needed or over architecting it.
There are those who would quickly point out the risk of under architecting a system, not looking to the future and not building a system that can change and grow. But the risks of over architecting are if anything worse. Too much architecture can equally prevent a system changing and growing, and too much architecture leads to more time consuming and expensive code to cut. Then there is the risk of not shipping at all, too long spent producing the "right" design may result in a system too late to be viable.
Second staff the team with people who are more generalist than specialist, people who have more than one skill. Yes have a Java developer on the team but have one who knows a bit of SQL and isn't scared of a little UI work. In time you might need to add database and UI specialists but delay this until it is clear they are needed.
These suggestions echo Conway's own conclusion at the end of his paper:
"Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity."
It is worth remembering that Conway was writing over 20 years before Womack and Jones coined the term Lean to describe Toyota.
Reverse Conway's Law & Homomorphic force
Since Conway wrote this a lot more systems have been developed. Many of these systems are now referred to as "Legacy Systems." In some cases these systems force certain structure on the team who maintain the systems and even on the wider company.
Given this situation the company has no option but to staff the team with three experts. Conway's Law is now working in reverse: the system is imposing structure on the organization.
Again this happens not just at the micro-level but at the macro-level. Entire companies are constrained by the systems they have. Economists might call this path-dependency: you are where you are because of how you got here not because of any current, rational, forces.
Underlying both Conway's Law and Reverse Conway's Law is the Homomorphism, or as I prefer to think of it: The Homorphic Force.
This force acts to preserve the structure of system even as the system itself moves from one technology to another, from one platform to another.
Both forms of Conway's Law and the Homomorphic Force pose a dilemma for any organization. Should they work with the force or try to break it?
I can't answer this question generically, there is too much context to consider. However I tend towards saying: Work with Conway's Law, not against it - like woodworking, work with the grain not across it. Be aware of Conway's Law and Learn to play it to your advantage.
Conway's Law does contain a get out clause: the system that will be created will be a copy of an existing system, if you can create a new system, a system not pre-loaded with assumptions and well-trodden communication paths then maybe you can create something new and of a better design.
Thus I sometimes view myself as an architect. Now I don't think I'd accept membership of the Architects-Club even if it was offered, and probably my software design skills are not up to the job but it doesn't stop me dreaming.
But I architect by (trying) to bring about a good organizational architecture which will in turn bring about a better system architecture via Conway's Law.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)