How and why your organization's structure matters to your product architecture
1: Product Architecture and Success
Great product architecture is integral to the success of a piece of software. According to MacCormack, "Product architecture has been shown to be an important predictor of product performance, product variety, process flexibility, and even the path of industry evolution." High marks in these attributes contributes to product success. Let's take an example.
Suppose you have two cloud products that serve music streaming services to millions of listeners. One was designed with an intelligent product architecture that fits the need at hand. Out the gate, it performs well. It's able to serve different types of music listener needs offering a variety of products with ease. For the developers, the sensible architecture makes the product easy to maintain and improve. This allows the team to be flexible and adapt to future trends. The other streaming service was designed with a poor product architecture. It's clunky. Out the gate, it's a little slow. It's only able to serve certain types of music listener needs because a lot of the information is hard-coded. Services and databases are poorly integrated. For the developers, the clunky architecture makes the product difficult to maintain and improve. This makes adapting the product to new trends difficult. Over time, the more intelligent product architecture turns out to be more flexible and more helpful. More and more users trend towards that product as it is faster, it better caters to their needs, it receives consistent updates, and it defines the industry. It wins.
But obviously there's a problem otherwise I wouldn't bother writing about this. Stick with me for a second. I need to explain something about how product architecture evolves and why.
2: Conway's Law and Organizational Structure
In 1968, Mel Conway published a paper. In a section of this paper, he argued, "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." This has become known as Conway's Law. Here's a quick example before I get to the problem.
Suppose you have five teams that comprise a consultancy's workforce at a client site. Let's say they were hired to redesign the corporate structure. Let's also say that they work in different offices and that the teams are super competitive. So they don't talk to each other much. Except for two of the teams who sit in the same office - they're best friends. According to Conway's Law, the structure they create will probably have five distinct groups - one for each of the teams. And two of those groups will be more integrated than the rest - the two that were developed by the teams that talked.
The argument: The structure of the organization, the routines that come out of that structure, and the communication patterns that result from these routines all constrain the organization's ability to think.
MacCormack and squad looked into this claim, and it largely checks out. They looked at commercial software firms with tightly coupled organizational participants and compared them to open source software communities with comparatively loosely coupled organizational participants. In all of the pairs that the research team investigated, the loosely coupled organization produced products with substantially more modular product architecture than the tightly coupled organization.
Ok so Conway's law stands the test of empirical evidence. But you're probably wondering why this happens. Here's a quick explanation (skip this section if you don't give a shit, but it's short so you should read it anyway).
3: Why does product architecture reflect the organizational structure?
- Designs may evolve to reflect their development environments, or
- Designers purposefully choose to create more or less modular products
In practice it's probably both.
Large, successful open source projects require a lot of volunteers and contributors. Potential contributors to projects select which projects they will work on. Naturally, they will seek to work on projects that require less effort for the same results. Components that have a lot of dependencies require a lot more work. So open source developers avoid them, and only the more modular components will survive.
Within commercial projects, however, there are less seed projects to choose from, and modularity is likely not a strong criteria by the business for project success. Instead, the business goals probably include measures associated with product performance like speed or memory usage. In this scenario, developers will not go out of their way to develop modular designs and will instead focus on meeting the goals set by the business. These goals could even lead to selecting against modular designs.
Ok so you're gonna be scratching ya head after you read the next paragraph. Like wtf do I do? Don't worry, I got you, just keep on keeping on.
4: Your Product Architecture Probably Sucks
Here's the problem: an intelligent product architecture is critical to the success of a product, but product architecture naturally mirrors the structure of the organization that created it. Unless your organizational structure happens to match the optimal product architecture, you will most likely end up with sub-optimal product architecture.
And most of the time, your organizational structure probably does not magically match the optimal product architecture for what you are trying to build.
So I thought about it... and took a look at research on the role of specialization and centralization of decision-making in (literal) architecture firms. In some sense, the entire role there is to design systems with intelligent (literal) architecture. Keep in mind that Conway has argued, "this theory has has traditionally been applied to Software, but it is not limited to any domain." So we're not going totally crazy here. Yet.
5: (Literal) Architecture, Specialization and Centralization, and Performance
First, let's assume that high centralization is an attribute of a stiff organizational structure. Think USSR. Inversely, let's assume that low centralization is an attribute of a flexible organizational structure. Possibly think your middle school pick-up soccer game. Fair? Ok, now I have something big to tell you. Sit down before you pass out. Don't say I didn't warn you.
According to some Nigerian researchers who investigated performance and organizational structure in Nigerian (literal) architecture firms, performance is positively correlated with low levels of centralization of decision-making.
(Maybe not as cool as I sold it. You're probably confused why I'm talking about this. Hold on.)
Given our assumptions, this translates to the following: performance is positively correlated with flexible organizational structures.
Ok, so keep that in mind, and now let's work through some kinda dense evidence and then try to come to a conclusion about what do we do now.
The finding in bold above suggests that "when architectural firms allow employees to participate in management, they profit more." According to Oluwatayo (that's that Nigerian referenced above), most of the high-performing firms exhibited decentralization. At the same time, most architectural firms in the study exhibited low to moderate levels of specialization (low specialization = a lot of multitasking) even though a high level of specialization leads to higher profit except in firms headed by inexperienced principals.
So let's say that the ideal organizational structure for an architecture firm would be (1) decentralized with (2) high levels of specialization.
Now think back to section 3 - large, successful open source projects are loosely coupled and have low levels of centralization of decision-making. Now let's just suspend all sanity for a second and apply the finding from (literal) architecture to software architecture. Assuming that the traits of a successful architecture firm translate to a successful software organizations, software organizations should have the following attributes:
- Decentralized decision-making
- High levels of specialization
6: Ok so tell me more about software
According to Craig Larman in his best-practices book, Scaling Lean and Agile Development (totally recommend it by the way), many software firms experience high levels of specialization because software development is highly knowledge-sensitive. Cool, so the software field is already hitting attribute #2 - high levels of specialization.
And it seems like open source projects are hitting decentralized decision-making. But it's not clear that commercial firms are. In fact, MacCormack's research indicates that they probably have very high levels of centralization: "organizational participants are tightly-coupled, with respect to their goals, structure and behavior." (Remember how we said tightly-coupled = strong organizational structure? Let's take one more step and say it also = centralized decision-making. It doesn't have to, but let's just say they go hand-in-hand).
Keep in mind that, according to MacCormack, tightly-coupled (centralized) software development often means a lot of direct and indirect dependencies - usually with a focus on performance, not modularity.
7: Conclusion // A top-down flexible specialized modular structure
Based on this research, I recommend that specialized resources should act within a modular organizational structure that mirrors a technical architect-designed product architecture. But this structure, this architecture, and these resources should be flexible. For structure, this means minimizing the cost of organizational changes. For architecture, this means designing a stable, low-dependency system with simple modular components and domains. For people, this means learning transferrable skills, not limited and impermanent domains.
All so that in the end, you have a flexible organization with simple and modular domains and components designed around letting specialized people apply their unique skills to complex problems. And then you'll get real performance.
- MacCormack, Alan, John Rusnak, and Carliss Baldwin. Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis. Massachusetts: HBR, 2007. Web. (http://www.hbs.edu/faculty/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf)
- Adedapo Adewunmi Oluwatayo, Dolapo Amole, Ownership, structure, and performance of architectural firms, Frontiers of Architectural Research, Volume 2, Issue 1, March 2013, Pages 94-106, ISSN 2095-2635, http://dx.doi.org/10.1016/j.foar.2012.12.001. (http://www.sciencedirect.com/science/article/pii/S2095263512000921)