mark nottingham

Modularity: Enabling Interoperability and Competition

Friday, 10 May 2024

Tech Regulation

Mandated interoperability is often highlighted as a way to improve competition on the Internet. However, most of the interoperability we see there today was established voluntarily: mandating it is relatively uncharted territory, with many potential pitfalls.

Giving policymakers a better understanding of how interoperability comes about could help. A regulator that appreciates the motivations and constraints faced when designing APIs has a better chance of identifying (in-)appropriate ones – even if their target isn’t willing to fully cooperate.

This line of thinking recently led me to a more than twenty year old resource that’s often called a “seminal work” but strangely isn’t cited much in either Internet governance or API design circles, as far as I can tell: Design Rules Volume 1: The Power of Modularity by Carliss Y. Baldwin and Kim B. Clark.

Their ambitions were not small:

[W]e want to explain how and why the computer industry changed from a quasi-monopoly into a large “modular cluster.”¹ […] In particular, one of most the important forces shaping the evolution of these designs was the drive toward modularity.

For me this was an engrossing read, even though (and perhaps because) a fair bit is already intuitive to a practitioner.

Chapter 3: What is Modularity? explains concepts like abstraction, isolation, information hiding, and interface that are well known in industry:

A complex system can be managed by dividing it up into smaller pieces and looking at each one separately. When the complexity of one of the elements crosses a certain threshold, that complexity can be isolated by defining a separate abstraction that has a simple interface. The abstraction hides the complexity of the element; the interface indicates how the element interacts with the larger system.

followed by a detailed explanation of ‘how individuals with knowledge can split apart a large design with many innate interdependencies, and thereby create a modular design and task structure.’

Chapter 9: Design Options and Design Evolution goes on to consider the economic impact of modularity:

It is useful to divide the large set of all complex adaptive systems into two categories: (1) systems in which the so-called adaptive plan is in the hands of a few agents; and (2) systems in which the adaptive plan is decentralized to many independent agents.

Yes, decentralisation fits in here too. Then, focusing on the benefits of the latter category of systems:

Modularization permits individuals (or firms) to mix and match alternative designs of the modules of a system. The “rights” to mix and match are options with quantifiable value in the greater economic system. A modularization multiplies design options and at the same time disperses them so that they can be “picked up” by many people, without the permission of any central architect or planner. The pursuit of valuable options by many decentralized actors in turn accelerates the rate of change of the system as a whole. […] Modularity creates design options and in so doing can radically change the market value of a given set of designs.

Chapter 14: The Emergence of Modular Clusters reinforces this:

A modular design makes possible decentralized design evolution. In the presence of advanced capital markets, a modular design also makes possible decentralized industry evolution. In other words, when an artifact with a modular design is created in an economy with advanced capital markets, subindustries of firms and markets organized around modules may emerge and evolve in parallel with the module designs themselves.

And then Chapter 15: Competition among Hidden Modules and Industry Evolution begins:

Modular clusters, by definition, “play host” to modular design evolution. Hence, unless and until an artifact design has been modularized, there is no cause for a modular cluster to form. Following a modularization, we have seen, there will be a concomitant multiplication and decentralization of design options. The number of workgroups engaged in design (and production) will go up, while, simultaneously, the forces of transactions and agency costs that tend to bind workgroups together into firms will diminish. Depending on the balance of these and other forces acting on the industry, a modular cluster (or clusters) may then emerge as a viable form for the industry to take.

In other words: yet more support for interoperability through modularity and decentralization as a remedy to competition and centralization issues – this time from an economic perspective. I think that’s important, because regulators have a lot more history with economists than they do with tech folks.

These are, of course, just a few highlights, and there are many more keen observations throughout; if you find these quotes interesting, I recommend you read the whole work.

I liked this book because there’s considerable value in having these observations written down in a well-reasoned, rigorous framework: it’s one thing if the industry says it does things for particular reasons in its many books about the topic, but it’s another when it’s done with the appropriate theoretical context and rigour from the ‘outside.’

I also enjoyed it because it ties together so many of the things I’m currently interested in: APIs, interoperability, competition, and decentralization. Critically, there’s also followup work which is even more relevant – but I’ll write about that separately.