The Three Economies an Introduction

For the last few years, during conversations with teams and executives across the globe, I’ve drawn a simple graphic on whiteboards, notepads and giant stickies, one that has led to many great conversations. It looks like this.

I think there is a book in that graphic and in those conversations… an exploration of Ashby’s Law, complexity theory, constraints (enabling/governing, top-down and bottom-up), reliability and emergent resilience, diffusion theory, the Commons and the enclosure movement (and recommoning), pluralistic logics and in the end more successful IT organizations.

So, this is the first in what I hope to be a series of posts (and maybe even a book) about rethinking how we conceive of the economics of software engineering and IT.

I call this graphic “the Three Economies,” because, of course, three is the magic number, but also because economic logics drive decision making in organizations, and the attempt to shoehorn IT into a single economic logic is not only misguided, but it does damage to the very organizations that need to transform the most. I want to think more deeply and publicly about the Three Economies, because I believe the software development industry is moving rapidly towards a platform thinking based paradigm, one that requires a new understanding.

To start with, let’s explore the concept of an economy. Simply, it is just the idea that an organization has a limited set of resources and they need to use some form of logic to apply those resources towards better outcomes for whoever is involved (themselves and their customers). Economics are logics that maximize the conversion of (constrained) resources into value. Even here the definition tempts us into a simplistic understanding that we should resist. What is value? Who defines value? How are resources constrained? When are they constrained? What is the process of conversion? How can that process be reproduced? What happens when constraints are removed, or changed? We’ll need to explore these ideas in more depth.

Current ways of thinking about software development tend to suggest a (false) dichotomy between Development and Operations. An understanding of The Three Economies requires an exploration of these conceptions of software engineering — not to devalue or falsify them, but to bound them within their particular relational contexts. Many organizations I speak with are trapped in a paradigm that imagines you can either be efficient or effective. Michael Porter, a key figure in strategy for a long time, had this idea that you needed to choose between operational excellence or a unique competitive position.

In order to create a unique competitive advantage, what you needed to do in Porter’s mind, was to create a clear trade-off between yourself and your competitors — differentiation.

Operational excellence, meanwhile, is the ability to deliver on that differentiated promise, efficiently and consistently. Porter argues that the source of value created here is Cost-based. But, Porter also argues that operational excellence isn’t itself a strategy — according to him, you can’t just do operations well and be strategically successful. You can create a competitive advantage through a focus on Cost, but there is a floor, once you get to $0 per widget, you’ve successfully completed a race to the bottom, congratulations. Differentiation has fewer limits… it would seem.

This is an argument that’s been driving IT for years: You can either be a value center, “Software is Eating the World” or a cost center “Deliver the same value for less cost at greater scale.” IT needs to transform from a cost center to a force multiplier… etc.

A value center is organized around maximizing the value of the competitive advantage of differentiation, it is organized around the logic (and context (or ecology)) of an Economy of Differentiation. A cost center provides, operational excellence that enables efficiency, it is organized around the logic (and context (or ecology) of and Economy of Scale.

While the logic of an economy of difference creates a unique and defendable position in the market, the logic of an economy of scale takes a value feedback loop — one in which we know that people will purchase something at a certain price point — and tries to create as much value as possible by squeezing all the waste out of the loop. As a result, the difference between the selling price point and the delivery price point gets bigger — in other words, in economies of scale, we move the bottom line down without changing the top line — and therefore we’ll make more money.

Economies of Scale also create situations in which people around us eventually notice that we’ve identified market conditions in which we can deliver some well-defined thing at well-defined price, this creates competition and eventually, there will be a price war, and only people who have operational excellence (disciplined execution in the reproduction of a specific process and outcome) AT SCALE will be able to continue to operate profitably. A really simple and common example of this is, if I wanted to personally administer machines (a thing I actually used to do once in my life), I could maybe administer 10 machines a day, constrained by the rate of change involved in maintaining those machines. Maybe I get really good and I’m managing 20, or whatever. But what I can’t personally do is what AWS does, which is to highly leverage servers administered per human. What’s being scaled at that point is the efficiency of having a defined output, a known state that you need to create, and the ability to reproduce that state.

Many organizations mistakenly think that there’s this choice between an economy of difference and an economy of scale. You need to focus on one or the other. You can either drive costs out of it or you can create value. There’s no in-between.

This is partially driven by the fact that these first two economies when they directly touch each other, are like grinding gears, the two logics don’t mesh. The math of differentiation and the math of efficiency don’t work together, instead, they oppose each other. In DevOps, Andrew Clay Shafer coined the term “the wall of confusion” — a wall of policy, and intermediation that goes up between operations and development, to prevent the grinding of gears, but at a great cost, to describe this strategy.

This false dichotomy between Differentiation and Scale, value and efficiency, is revealed for what it is by the introduction of a third economic logic. The problem isn’t choosing between these initial logics, but instead expanding the way we understand IT works with a third economy.

This third economy acts as a clutch. It’s a way of translating efficiency into difference. This third economy is the Economy of Scope.

We need to clarify the difference between the economy of scope the economy of scale right away as they are often confused. The economy of scale is driven by things that can be consumed. In IT, this means things like network, CPU, storage, etc. These are things you can use up. If you use your network, you can saturate the limited amount of bandwidth available. So you need to manage in order to be able to (re)produce the network, the capacity, the compute, the writes per minute, etc. All these things are consumables. If you use them, they “go away”. Scale economies require managing how people get access and how much access they receive to these consumables. Scale Economies limit variability (of consumption) by CONTROLLing access.

A scope economy is different because the value produced in it is based on things that gain value in great (re)use. For instance, if we have a customer record that’s really nicely well-formed, it becomes more valuable if lots and lots of people use it (compared to lots of people having lots of different models of the customer). Same thing with well-formed functions. If we have a login function, and we share that same login function among many, many applications so it gets reused a lot, the value of that function or that service goes up, not down.

Scope economies (platforms) are made up of things that are found in scale economies. A platform is made up of network, compute, storage, etc., but what’s added to it is the reuse of functionality and data. It’s also made up of predefined configurations (patterns of configuration) of what I’m going to call primitives — network, storage, database, compute. A platform configures those primitives in a certain way to make them more easily accessible by developers. But it also limits the amounts of variation in those configurations, so it makes it more stable and reduces the combinatorial complexity of the system, creating resilience out of mere reliability. Well-formed functions, reusable data, and predefined or standardized configurations. These three things create a platform, which performs the logic of an Economy of Scope, which allows you to have a clutch between the logics of differentiation and scale.

Therefore, scope economies should not be measured by how efficient they are and shouldn’t be measured at all by how much differentiation they create. They should be measured by how quickly they’re adopted and how effectively they isolate efficiency from differentiation.

When a platform isolates efficiency from differentiation, the differentiation gets thinner, but also faster. As an example in a recent article, Facebook rewrote the Messenger app, and they took 1.7 million lines of code and reduced it by 84% to 360,000 lines of code, just by leveraging the preexisting framework inside of iOS. They basically leveraged the iOS platform to make the messenger app, the differentiated edge system, as small as possible. This means it goes faster, it’s easier to maintain, and it’s easier to dispose of.

So, Three Economies. You’ve got an economy of difference, an economy of scope, and an economy of scale. You have to learn to manage all three economies, all three different kinds of logic, and you have to not mis-apply the logics to the wrong parts of the system.

I’m looking forward to exploring these ideas with you. Please ping me on twitter with questions and thoughts.

(h/t to Ben Mosior @hiredthought for his contributions in bringing you this writing)

(h/t to Cat Swetel @catswetel & Ben Mosior for exploring these ideas with me for the last few years through patient questioning, explorational conversations, and a nearly endless reading list)