Traditional products are not very scalable: It takes a logger twice the time to chop down two trees instead of only one. Mass production changed this rule of labour dramatically. It does matter wither Mercedes produces only a handful of cars or thousands every day. This is not only due to the fact that bigger machinery leads to smaller costs per piece. A significant part of the price of modern products are the costs for developing a product. It takes millions to get a new car released. These costs are less per piece the more pieces you produce.
This effect plays an even greater role for software. The lion’s share of software costs goes toward the development since its easy and very cheap to copy and distribute software today. Pack it on a sever and everyone can download it from almost any place worldwide.
This is what we mean by scalable: Develop your product in a way that you can sell it to as many customers as you can without any extra costs.
“Isn’t that always the case with software?”, you might ask. Unfortunately it is not, as I mself found out in a hard learned lesson. The SAP product family for example is not. Although I know almost nothing about SAP I guess its safe to say that almost no SAP installation is the same as another. Tons of consultants need to go to the customer to adapt the software to the customers needs. Thats probably also one of the reasons why they are not very successful in making small companies their customers. It is just too expensive for them to pay for all that adoption work.
Over the last year I helped to restructure a SAAS company who distributes a SRM system (actually a pretty good one). They wanted to be a SAAS company with a scalable product as described. But unfortunately they were not. What had happened?
They had 3 customers (Lets call them A, B and C) who all used the same code. The code was already a number of years old when a new software architect showed up. He looked at the code and decided it was not maintainable anymore and lots of stuff needed to be re-factored. The idea was to start with one customer (A) and after the refactoring was done to move the others as well. They started the refactoring and it took a lot longer then planned. Some new feature requests came from A and had to be implemented as well. In the meantime one of the other customers (B) had many new feature requests and enough money to pay for them, but they of course wanted them right away. For that reason the management had them implemented in the old code base.
When I came to the project the situation was as following: Customer C was still running on the old code. Customer B had many new features implemented but not in the refactored code. Customer A was running on the new code base but with much fewer features. Not a nice scenario as you can imagine and not scalable at all. In the end we decided to go with the code base of customer B and implement there the few new features of customer A and to then move all customers to this single code base. The refactoring was a total loss and the merge of the different code bases took several months and countless hours.
That was an expensive lesson I had to learn:
- Never, ever let your code split up into different code bases
- Run all your SAAS customers on the same code
- If you release, release for all of them at the same time
Only that makes a system truly scalable. Everything else causes lots and lots of work.