Volatility and Software Architecture

Change is the only constant. But without further framing this particular truism isn’t very useful for informing how you ought to architect your system.

I'm making my way through Righting Software by Juval Löwy and have to highlight his concept of the axes of volatility as a way to address the fact that changing requirements are a given in software. This technique frames the way that you analyze and build your software systems. It forces you to consider two different angles of "the customer".

The first is with a single customer over time. Where they are, and where they will be in their business lifecycle.

The second is across all of your current customer base frozen in time.

A Single Customer Over Their Lifecycle

You may be able to happily meet the needs of a single freelancer just starting out with the product as is, but it may be wholly out of touch for a Fortune 500 company. Or the reverse may be true.

This is the power harnessed by tools like Less Annoying CRM, or Basecamp. They aren't attempting to meet the needs of all possible customers across their business context/lifecycle. Instead they are purposefully stating that our product is for our ideal customer profile, smaller businesses that believe in opinionated tools, and if you don't fit that criteria, either now or in the future, we're happy to say that "you've outgrown us".

Your Current Customers Frozen in Time

Are you meeting all of their needs currently? If not, where are things lacking? If you were to add a large number of customers all frozen in time at the stages you currently serve well, how would your system respond? This second framing opens up two different angles. The first is similar to the one opened by the first axis, which is across what business context does your solution make sense? The second also has implications for scaling. If you look at if you were to add a large number of customers that you're currently serving well, how would things hold up?

Your Organization as the Customer

How things hold up segues nicely into the final way I've found this framing useful so far. Use your organization as one of the customers that you frame architecture against. Where is it in the lifecycle? And how far into the future can, and should, it reasonably be able to forecast?

As a small startup that is pre-funding or seed, you're unable to meaningfully forecast into the future. Finding out how to meet the needs of a small number of customers as quickly as possible is the best path. Optimizing for scale will result in you having a bad time before you know what problem you’re solving, and whose needs you’re meeting.

As an established business building product for your existing primary customer base you should be able to better forecast around scale, and can build accordingly. But if you were to add a new customer segment that your business doesn't have familiarity with, or knowledge that the product you're building will meet their needs, you ought to use that to segment the areas of your architecture that are likely to change.

Containing the Blast Radius

This framing gives you paths for containing architectural missteps into a known blast radius. The parts of the business you do understand don't need to change, while the parts that do can be confined.

Let's step out of the abstract to try to make this a little more concrete.

If you've already got authentication and authorization handled for customers ranging from the individual starting a business to a Fortune 500, whether through an internal service or external one like Auth0, then that area isn't going to be very volatile for your organization. If it does change, the damage is likely contained to that service.

But if you've only handled permission systems for the "small business" customer segment, you're going to need to make some changes to your permissions system to facilitate the Fortune 500. Given that, you want to design your system so that the blast radius of the changes is isolated to only affect the part of the application that handles authorization. This means providing an interface that will allow you to make changes inside the authorization service, without needing to change the consumers of that implementation.

These two angles can provide great insights into how to minimize the blast radius of changes to your architecture based on changes to customer needs.