In our last post we covered some of the history and reasons that the Relational Database Management System (RDBMS) became the database of choice for SaaS. This week we’ll discuss why the ability to “segment” the database to support multiple customers with their own “copy” was critical to being able to create the SaaS business model. For you technical folks out there, I’m a business guy, so the analogies are to help provide an understanding, rather than to be technically correct.
When the RDBMS was first implemented, the assumption was that one customer would have multiple applications. Each application could have its own RDBMS schema, and one RDBMS might have multiple schemas.. The critical viewpoint was that each application schema would support one customer.
But what if you turned the paradigm on its head and had one schema shared by multiple customers, with each customer’s data being secured from another? In that scenario, the operational cost (licensing, computer infrastructure, upgrades, etc.) would be significantly less than having to provide one RDBMS per customer. An application provider would only have to test for and maintain one version of the database. When the provider made a change to the schema, all customers would be instantly upgraded. One bug fix would support all customers at the same time. Having this capability would dramatically lower the cost of supporting an application, and the provider would have the potential to upset the existing application cost paradigm.
An analogy here is that prior to SaaS, each application was like a family in the suburbs living in its own house separate from other applications. While being in a separate home is great for customization, it is relatively very expensive to maintain than shared living quarters, as each house is custom built for its family or tenant. Services, such as gas, water, sewer, electricity, etc. are unique to each house. Upgrading these services is expensive and each home has to be upgraded individually. Contrast this to a multi-story apartment building, where, while there may be fewer customization options (for example, one or two bed floorplan options), it is a lot cheaper to build and maintain multiple dwellings because they share the same services. Upgrading a service into the building immediately covers all tenants. For most companies (starting with small and medium sized firms), the simplicity and cost avoidance of having to take on management of the RDBMS would be extremely compelling.
It was the realization of the implications of the lowered costs, more rapid development and improved application product quality that set Salesforce and NetSuite on their way to upset the packaged application industry. The founders of both firms came from Oracle, where the database was king. There were many technical hurdles to be addressed – how to support hundreds and thousands of customers on one RDBMS (from single users to 10’s of thousands of users per customer), how to scale the number of transactions, how to scale the volumes of data from those customers, how to keep the database running almost non-stop, and how to upgrade the database in very small time windows. Those issues were addressed admirably by the data base vendors.
As mentioned in previous posts, there were other pieces of the technology puzzle that also had to be available in order to build SaaS applications; but with a “multi-tenant” architecture, a shared database became extremely compelling to new application developers.
Next week we’ll look at why Salesforce was smart/lucky in targeting sales teams for its solution, and how that user group was critical in breaking down the barrier to SaaS adoption in medium and larger organizations.