Customers often ask us “When should we invest in scalability?” The answer that we want to give, and that’s financially correct for your shareholders, is to deploy your scalability improvements the day before you need them. If you could deploy scale improvements the day before the lack of those improvements would cause problem, you would delay investments to be “just in time” and gain the benefits that Dell brought to the world with configure to order systems married with just in time manufacturing.
But most of us have a hard time predicting when we need to deploy that next scalability improvement and an even harder time getting the project to come in just at the right date. To that end, we developed the “Design-Implement-Deploy” or “D-I-D” approach to thinking about scalability. Because there are multiple phases to any product enhancement, including the phase in which you start to think about it and design it (even if it’s just in your head), the phase in which you actually “code it” and the phase that you deploy it to production, we matched these phases to your needs for scalability. Note that these phases don’t argue for a waterfall model. If you are developing using Agile methods, you still hopefully “think” about how something might look or work before you start coding or developing it.
We start with the notion that discussing and designing something is significantly less expensive than actually implementing that design in code. As such, we should be willing to spend more time discussing how we might scale something and sketching out a design for that scale well in advance of our need and to an extent significantly greater than our need. We should, for instance, discuss how we might scale something to at least 20x greater than what we have now and ideally to nearly infinite capacity. Many times, in SaaS environments, we could facilitate such scale along the Z axis by dedicating systems to individual customers though this would cost us a great deal and would break the leverage achieved by multi-tenancy. Nevertheless, discussions such as these are beneficial to help us figure out what we need to do in the future and to what degree we need to scale our systems. The focus then on design of the D-I-D scale model is on scaling to between 20x and infinity. Intellectual costs are high, but engineering and asset costs are lower because we aren’t writing code and we aren’t deploying systems. Scalability summits are a good way to identify the areas necessary to scale within the design phase of the D-I-D process.
We should then move to implementing our designs within our software, focusing on ensuring that we can scale to at least 3x our current size and up to 20x. There might be cases where the cost of scaling 100x (or greater) our current size is not different than the cost of scaling 20x and if this is the case we might as well make those changes once rather than going in and making those changes multiple times. This might be the case we are going to perform a modulus of our user base to spread across multiple (N) systems and databases. We might code a variable Cust_MOD that we can configure over time between 1 (today) and 1,000 (5 years from now). The cost of such changes are high in terms of engineering time, medium in terms of intellectual time (we already discussed the designs earlier in our lifecycle) and low in terms of assets as we don’t need to deploy 100x our systems today if we intend to deploy a modulus of 1 or 2 in our first phase.
The final phase is deployment. Using our modulus example above, we want to deploy our systems in a just in time fashion; there’s no reason to have idle assets sitting around diluting shareholder value. Maybe we put 1.5x of our peak capacity in production if we are a moderately high growth company and 5x our peak capacity in production if we are a hyper growth company. Asset costs are high, and other costs range from low to medium. Total costs tend to be highest for this category as to deploy 100x of your necessary capacity relative to demand would kill many companies.
The focus of your scale factor (20 to infinity, or 1.5x to 3x moving from design to deploy) varies with your rate of growth. If you have 10x annual growth, you are going to want to be on the high end of our ranges whereas if you have 10% annual growth you can be on the lower end. The chart below summarizes the discussion above.
