I will do my best to clarify what the term ‘scale’ (actually) means.
TLDR
Technology Scaling is not Business Scaling although they can work together for success
Servers / Infrastructure is a tiny fraction of the overall scaling discussion
Servers / Infrastructure falls under Technology Scaling
All the servers in the world does not mean you are scaling
Core Code + Delivery is the ordered combination that should be followed to achieve technology scaling
There is a side of the scaling conversation that involves physical locations!
Business Scaling is another ball game that I might address much later
Let dig in!
The questions ‘Will it scale?’ and ‘Is it scalable?’ are very common in the software product / technology domain.
A lot of people just think of only servers and infrastructure. There are groups of people that only think physical locations and nothing else. Most people are just outrightly clueless and do not even know what they mean when they talk about scaling/scalability!
Allow me to guide you beyond buzz words and theories (ahem ‘blitzscaling’). When addressing the question of scale think of two main categories, namely:
a) Technology
b) Business
Technology scaling is not business scaling and vice versa. However, if done correctly both can work hand in hand for greater success. I will tackle technology scaling first then later in subsequent parts, I might break down business scaling.
Let me start this technology scaling lecture with laying a foundation by saying this, if you have all the servers in world, all the cloud instances in the world and the core of your software product is in shambles you cannot scale! In such situations, when asked if you can scale you should not answer yes, at all.
For any software product to scale technologically, you require two things: 1) Core Code 2) Delivery. These two (2) areas are what you should consider when talking about technology scaling.
To understand this, consider two sides of the spectrum: Side One, making software for others to use. Side Two, relying on software to thrive. Stay with me I don’t want you to get lost. This is building on the foundation laid above. I will start with Side One to explain technology scaling.
Side One (Making software for others to use):
Consider a company that provides a solution to other companies. Company A has Client A as a customer. Client A is a good customer and wants to recommend Company A to members of their association. So, twenty new customers approach Company A but their Core Code is not as it seems. To carter to the twenty (20) new customers, Company A has to fork the code base each time. So now they have twenty (20) different codebases, one for each of the twenty new customers. Company A realises they are in soup and cannot take on new customers. They cannot scale because their Core Code cannot scale. Their Core Code is not scalable so they aren’t scalable! Any new customers that come along means newer forks so they simply turn them down. Do you see where this is going? Not yet? Keep reading. Now for each customer that Client A helped bring in they have servers doing server things (cloud, serverless, whatever). All the compute, storage, database and networking Company A deployed for each customer makes it seem that their solution scales, but that is false!!
Side Two (Relying on software to thrive):
Consider a company that needs a solution to aid them accomplish amazing things in their industry quickly and without hassle. Company B meets Vendor B to adopt a solution and move on with their activities. Along the line they (Company B) realise every simple tweak needs the software vendor. They cannot create extensions, plugins, other things that will give them some sense of freedom as users of the software. As if that is not emotionally draining enough this company’s users keeps growing but the Core Code from Vendor B is not allowing Company B to soar as their user base grows. Apparently, the vendors of the software (Vendor B) did not design it for massive use but rather for a company with no intention to grow to millions (and even billions). Ouch!
With the spectrum laid out atop the laid foundation (I think) you should better understand technology scaling. There is an order of things to achieve tech scale. And that order is Core Code first then Delivery second (it’s ok to disagree with me but my experience has shaped this opinion). Most people make the mistake of discussing parts of Delivery and think they are addressing the scaling question but that is a huge mistake! I will do my best to describe Core Code and Delivery below:
1) Core Code: this is the code at its core! How it is designed, written, structured and organised. This is where the scaling analysis begins (or in my opinion, must begin!). If this box is not ticked (and ticked well for that matter), forget any servers or cloud infra you have in place. If you are a software vendor/author, take out considerable time to address this part of the scaling discussion. If you are an organisation shopping for software, ask questions about this area. So, what makes a great/solid Core Code? Over the years I have created a detailed checklist of areas that needs to be addressed but I’ll list a few pointers here. These pointers take the form of questions and statements that will serve as a guide. I will also try to use examples existing in the market.
Statements: Never confuse setting up and signing up as the same thing, they aren’t. A solid Core Code is not custom built for just one person but rather for the general market with the liberty to modify per their needs. A system with a solid Core Code has to be API first and the APIs have to be error first APIs. Being modular really helps in keeping a clean codebase at the core. A solid Core Code will evolve into a community that includes not just users but service providers and developers as well. A great Core Code is delivered by a solid and well thought out development pipeline. It is not every type of software that will need to provide a system for the masses to create plugins but internally it is a useful way to move quickly and efficiently.
Questions: What is the setup process of the software and how easy is it to complete? How easy is it to signup? How are accounts managed after signup? (Individual accounts, company/organisational accounts, accounts hierarchies and possible transfers, accounts cancellations/deletions, accounts updates/modifications). What are the defaults for every action along the way? How will pricing be enforced/implemented? These are just a few questions.
To further understand ‘Core Code’ in the way that I see (and understand) it, I will use one of my favourite opensource projects, Drupal (I will not discuss Acquia here). Every user gets a foundation copy of the software and sets it up in their own environment. It is not a custom software for only one person/organisation. Typical of any solid Core Code is the foundation copy given to users. This copy is usually a plugin architecture that enables the users to build their own modifications (modules, themes, distributions) or obtain one from any trusted marketplace. This freedom offered by the software allows users to address any needs that may arise. It does not lock down the vendors to just one user but allows multiple users to get the software. It also does not cage the users as they can modify the software by adding new capabilities. Achieving solid Core Code for SAAS vendors is somewhat different since they want customers to use the software on their domain (ie the vendor domain). But the idea is relatively still the same. Give the user a foundation copy and the option of adding modifications (created by them or obtained from a trusted source). Think Shopify and how we now have Shopify developers and a thriving community. There are other SAAS vendors in other areas asides ecommerce that give their users such freedom.
In the most basic form this is what it means to be able to scale at the Core Code level of the software! A foundation copy, the user can then extend/modify per their needs/use cases!!
2) Delivery: the means by which you get the software product into the hands of the user. If this box is ticked and the Core Code is not ironed out properly then (in my opinion) you have a problem! Delivery is basically how your product gets to the hands of customers in the market. Delivery is easy when your Core Code is in order from all perspectives (design, processes, architecture, etc).
Back in the day CD-ROM was the way many vendors got their software in the market for the customers to purchase. Then some software authors started providing copies via downloads from their website. These days you can visit a vendor website to download an installation file. Some vendors simply have you use the software on their website without the need to download anything or leave their website (ahem ahem SAAS)!
You can choose just one method of delivery eg only CD ROM (this still exists today), only installation downloads from the website to the users’ computer, or only allow entire software usage on a website so there is no need for user downloads (basically SAAS). OR
You can choose a combination of methods eg provide CD ROM for users but to complete the setup the user has to be connected to the internet to retrieve vital information from your servers (also useful for updates after CD ROM installation), installation file from the website that connects to the internet during the setup process, provide the user the software on your website but provide an offline mode so the user can use it without internet connection, provide installation via your website but also have a version that allows the user to do their work on your domain as well (Microsoft does this with MS Office where you can install the software on your computer but also use it on their website as well). Allow the user to install the website on their computers so when they tap the icon it opens your website (PWA basically).
This is Delivery, the part of technology scaling that finds ways of getting your software to the customers. The mistake people make with delivery is they jump straight to SAAS and close their eyes to various other methods of ‘Delivery’ (what can be learned or perhaps combined together). They jump straight to the server/infrastructure conversation without asking how individual users (and their activities) will exist on their domain.
The Delivery bit is where people start (and end) the scaling conversation, and it is so wrong! Imagine having a horse push a coach with you inside it. You keep beating the horse because you feel it isn’t pushing the cart properly and fast enough. That is what is happening today. For goodness’ sake the horse should not be pushing the cart!!
Do you remember the two spectrums from earlier? Side One and Side Two (the ones laid atop the foundation statement)? If the software vendors/authors followed the order of having a solid Core Code and then easing into an in-depth planning of Delivery, then actual distribution of the software will be easier thus achieving technology scale. This way the vendors will not be locked to one user (or a hand full of users) and targeted customers will not get stuck along their journey in using a vendors software product. This is valid for any type of software product across any business model (B2B, B2G, B2C, etc).
Most people have not understood the problem deeply and thought through how to put in place Core Code to address the problem and how in-depth Delivery plan will further support this Core Code. But they jump into talking servers/infrastructure (which is a small piece of the overall Delivery discussion). And it is usually in the line of: … a SAAS platform with adequate server instances ‘so they can scale’, let’s use microservices ‘so we can scale’. With the excuse of “moving quickly” many software authors have skipped critical steps that needs to happen, in favour of trends and buzzwords. It is terrible to watch.
To scale technologically you need to follow an ordered combination of Core Code + Delivery. Your Core Code first then the Delivery second. This is not a surface level conversation. You should have a deeper conversation into these areas individually and as a whole combination. This is what it means to have technology (at) scale.
I am interested in hearing your thoughts about my opinions on the scaling conversation. In what area do you disagree? Do you find it misleading or is it a great guide? Is there anything you want me to further explain?
In another part of this opinion piece, I might address another category of the scaling conversation, Business Scaling.
