Ray ValdesThis week at the Gartner Web Innovation conference, I participated in an interesting panel discussion with fellow Gartner analysts. At one point, the discussion lingered on a favorite topic of mine, that dictum known as Conway’s Law.
If you are not familiar with this bit of wisdom, it originated with Mel Conway back in 1968. Wikipedia has good background on it. I’ve seen Conway’s Law stated various ways. The way I usually articulate it is:
“The structure of a software system reflects the structure of the organization that built it”.
In presentations over the past two years, I have drawn out various implications of Conway’s Law, such as:
- If you have a development team with a dysfunctional organizational structure and warped lines of communication, you’ll get a piece of software that is equivalently warped and misshapen.
- If your organization outsources development of a system to a small, tightly-knit, highly functional team, the happy circumstance might result that you accept delivery of an elegant jewel of a software system. However, once your organization takes responsibility for maintenance, in many cases, the shape of the system will, over time, tend to “snap back” and reflect the bloated or misshapen structure of the new owner.
- Therefore, if you are a newly arrived manager or architect that has inherited this kind of legacy system (and trust me, I have been there), you need to be aware you are fighting an uphill battle to restore this misshappen mass of spaghetti-code to its original elegance.
- That is, unless you follow my recommendation which is: before refactoring code, consider first refactoring the development team. This will improve the chances for success with your software rearchitecture initiative.
In a followup conversation, my Gartner colleague Nick Gall, one of the most erudite people I know, points me to a 1996 article by Sanchez and Mahoney (via Langlois), which states a counter-principle to Conway’s Law:
“Modular product architectures create information structures that provide the ‘glue’ that holds together the loosely coupled parts of a modular organization design.”
What this means, in other words, is not that the structure of a product reflects the organizational structure, but rather that the structure of a product can reflect back into and reshape the organization. Observing these two opposing dynamics, Nick muses: “Seems like there might be a complex interplay between the two.”
This got my wheels turning. Both principles (Conway on the one hand, and Sanchez/Mahoney on the other) have a certain validity. How to reconcile?
I believe the key to this conundrum centers around the relative malleability of the product compared to that of the organization. I would phrase this as:
If the product or artifact is malleable (as many software systems are), then the organizational structure will reshape it. On the other hand, if the artifact is a closed device or system, it can instead reshape the organization.
That is, sometimes the product is a rock, and sometimes it is a soft place. Likewise the organization. If the product is a software system for which the organization does not have the source, then it is the rock, and the organization is the soft place. In the opposite scenario, if you drop a closed device such as a mobile phone into an enterprise, it will leave an impression upon impact, for sure. This interplay between artifact and organization works at a societal level, not just the enterprise level: for example, the automobile reshaped America into undifferentiated suburban sprawl.
Not all software systems are malleable. For example, some ERP systems can be viewed as a Procrustean bed upon which the organizational structure is drawn and quartered and reconfigured — although this may require a small army of consultants to perform the surgery. After the operation, the organization ambulates off into the distance, and is unlikely to revert to its original form as long as the ERP harness enveloping it maintains its rigid constraints.
A scenario with a disastrous outcome is where the rock meets the hard place: where neither the software nor the organization is malleable. This is where one enters the land of lawsuits. Or an alternative scenario, where both are somewhat soft, and “devolve” into non-optimal shapes: an ERP system gets customized into spaghetti, and the organization gets re-engineered into dysfunctionality.
Not to fall completely into cynicism, I grant the possibility that positive outcomes exist: synergistic scenarios in which both the organization and the artifact co-evolve to a better place. My question to you: when and where have you seen this happy circumstance?
Category: Uncategorized Tags:
7 responses so far ↓
1 Thomas Otter September 19, 2008 at 5:27 am
Ray,
Super post.
This made my morning, especially this bit.
Not all software systems are malleable. For example, some ERP systems can be viewed as a Procrustean bed upon which the organizational structure is drawn and quartered and reconfigured — although this may require a small army of consultants to perform the surgery. After the operation, the organization ambulates off into the distance, and is unlikely to revert to its original form as long as the ERP harness enveloping it maintains its rigid constraints.
If one looks at ERP vendors, one can draw a pretty accurate organisation chart by looking at the architecture and its silos and integration points. the fault lines follow politics. As politics shift, one can see the changes in the code releases.
At the risk of linking to my other blog ad nauseum, you might enjoy this
http://theotherthomasotter.wordpress.com/2007/06/06/in-defence-of-concrete/
2 Ray Valdes September 19, 2008 at 5:29 am
In case one thinks the above article is abstruse conceptualizing, here’s an important real world example of how organizations devolve software systems. According to an article in today’s New York Times, “How Wall Street Lied to Its Computers” (http://tinyurl.com/3e63e9), it appears that software systems for risk management had built-in blind spots, due to a variety of reasons including complexity of financial products, complexity of computer models, and complexity of organizational processes.
3 Ray Valdes September 19, 2008 at 5:35 am
Thomas’ comment slipped in. To be clear, the phrase in my comment about “abstruse conceptualizing” was referring to my original post, and not to that of my esteemed colleague
His blog has some great photos of concrete, btw.
4 Meg Bear September 19, 2008 at 10:44 am
Your question was this: both the organization and the artifact co-evolve to a better place. My question to you: when and where have you seen this happy circumstance?
And my answer is probably going to surprise you. I think that the ORCL Fusion products are actually an example of evolution for the good. Bringing together such large systems as the offerings of Oracle eBusiness Suite, PeopleSoft Enterprise, JD Edwards and Siebel Systems has shown an evolution for the better of both the organization as well as the products.
While still large and reflecting the silos of our organization (we are a large group so this is inevitable) I think people will find that there has been a lot of synergy and growth for all involved as a result of a product attempt such as this.
5 Ray Valdes September 20, 2008 at 2:38 am
Meg, thanks for your comment. Great blog you and your colleagues have, btw.
6 Implications of Conway’s Law on Enterprise Systems « Anthony’s Blog September 20, 2008 at 3:23 pm
[...] under: Web 2.0 in the Enterprise, Web Applications | Tags: Conway’s Law | You’ve gotta read this great post from Ray Valdez [...]
7 Lori MacVittie October 2, 2008 at 10:38 am
Ray,
I hadn’t been aware of Conway’s law before so this was very interesting, especially when applied to SOA and BPM. It certainly provides an explanation as to why so many business process re-engineering attempts either (a) take years to implement or (b) fail outright.
Great post, though I’m guessing that re-factoring code is still a lot easier than re-factoring the organization and/or its processes. You can re-factor code with a few clicks of the mouse, you can only re-factor the organization through painful restructuring and,usually, changes in management.
Lori