Conway's Corollary - Design Determines Scale

When I went to business school, I worked closely with an incredibly smart woman with whom I shared a very similar method of thinking and mindset. When we would find the same responses to the same questions in the same manner, inevitably I would quote, "great minds think alike."

She taught me that there is a corollary: "...but fools rarely differ."

The great challenge in life often isn't to agree with someone, no matter how smart; it is to determine if you are both great minds thinking alike, or both fools who are not differing.

I have written before about Conway's Law, which states, in short:

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

Recently, I came across the corollary to Conway's Law. If the organization determines the design (or architecture), then the corollary is:

Organizations are constrained to the cost and speed of scaling a system based on the design of that system.

I recently had breakfast with a friend, longstanding technology executive, whom I greatly respect. He was explaining to me why his cloud systems require a lot of labour to scale.

Unfortunately, the term "cloud", heavily overused, seems to be applied to everything nowadays. However, true cloud, especially applications, as I have written before, like true SaaS, has a very specific meaning.

It is not where I run your dedicated application for you on servers, so you do not have to deal with hosting, networking, managing it and upgrades. That can be very valuable to customers, but it is not true cloud. True cloud is where I run a identical copies of my application with multiple customers running through it; any customer can connect to and use any copy of my application. If I have individual instances of the application(s), let alone individual servers, per customer, that is not true cloud.

Does that mean you never should run per-customer instances? Of course not. There are many situations where you may need per-customer instances or even servers. Your business model may depend upon it. But you will not get cloud-scale speed or costs in a per-customer model.

My friend's issue was that he did not have true cloud due to architectural decisions made at the software level. If you have 50 customers, and each has their own instance of the application, that is:

• 50 application instances
• 50 databases
• 50 sets of configuration

If you have multiple application servers - Web, app, multiple databases, etc. - per customer, then the total number keeps as well.

No matter how much automation you do, the lack of immutability and identity of each instance compared to the other means human effort to support and manage each one, as well as unique errors for each one. It also means upgrades are not performed once across all customers over 3 hours, it mean they are performed 50 times, once per customer.

Well, at least each customer is faster, right? Won't each take less time, say 2 hours?

In theory, yes, although that is not much of a consolation. 2 hours times 50 customers is still 100 hours, far worse than 3, or even 5 or 10 hours.

But the real pain is that because each customer has their own instance, it becomes too easy over time to make each one unique, and to create processes and assumptions that depend on that uniqueness. After all, why spend 40 hours engineering a cross-platform solution if you can solve "just this customer's problem" in 3 hours and be done?

That uniqueness - lack of identity - means that the time to upgrade a customer actually will be more than if it had been shared. It means the 3-hour upgrade for everyone doesn't become 2 hours per customer times 50... it becomes at least 50% and more likely 100% more, or 4.5-6 hours per customer.

An upgrade that cost 33 times the alternative just became 100 times the alternative. This is all because of design.

While you may be constrained to designs that reflect your organization, you definitely are constrained to scaling costs and and speed that reflect that design.

How do you solve it?

1. Design as "true cloud" as you can. Not only does it give you the scaling costs and speed you want directly, it also forces you to design tools and processes in a way that support those operating methods.
2. If you cannot design "true cloud", design everything else as if you were in true cloud. Must have an application instance per customer? Make it run as automatically as if it were for all your customers. Require per customer IP address? Make IP address deployment as automated as if IP didn't matter. Never ever do per-customer customization or manual setup. Simple test: if the customer's instance died today, would it restart automatically elsewhere in seconds?
3. Constantly reevaluate every part of your design. Find the parts that do not scale and change the designs - and processes caused by them - to support cloud scaling. It looks expensive now, but the returns pay back in spades. Be fearless about changing things.
4. Change small things all the time, big things regularly but less frequently. Do not hold out for perfection. Every little thing you change frees up time and effort to focus on more things. These are force multipliers.

Summary

Your organization constrains your design, but your design constrains your scale, costs and speed even more.

Invest in fixing your designs, even the small things, and constantly reevaluate. Not sure where to begin? Where to get the biggest return for your investment? Ask us, we love helping you scale.