Ratnesh Singh Parihar
Having worked as a solution architect and designed multiple SaaS applications, I believe many companies have struggled to choose the right SaaS architecture for their product offering. In this article, I will share my learnings to help companies that are building SaaS applications make a pragmatic decision about product architecture, while considering its impact on pricing and profits.
The pay-as-you-go pricing model has gained popularity because of the increased flexibility for customers. However, to enable pay-as-you-go, you need the right product architecture to support it, such as tracking the use of services and offering customers the flexibility of managing infrastructure as per their requirements.
A poorly designed SaaS architecture creates limitations in setting the pricing strategy for the offerings and impacts new customer acquisition. Conversely, a good architecture sets the appropriate pricing model and accommodates special architecture-design requirements, while enabling scalability and customizability.
Before setting up a SaaS architecture, it’s important to answer these questions first:
- How would the customers pay?
- For what services (computation and values) would the customers pay?
- How will the usage be measured and invoices be created for the customers?
In a SaaS setup, costs incurred in managing operations impact profitability to a large extent. Operational expense optimization involved in managing the SaaS model depends on three crucial factors — infrastructure cost, IT administration cost, and licensing cost.
However, the bigger question is: How do you ensure that these costs are well-optimized and priced correctly? Here are a few examples:
Salesforce Online: Salesforce provides a lead management system for enterprise sales and marketing teams. The online version uses the cloud to reduce the hassles of hardware and IT procurement. It also charges customers based on the size of sales and marketing teams to stop the payment of one-time high license costs.
Azure SQL: As the RDBMS (relational database management system) leader, the SQL server provides a hosted solution where customers pay a high license cost and hire a DBA (database administrator) for regulating backup, geographical replication, and disaster recovery. But Azure SQL is a cloud-based system that is accessible online and you pay only for storage and IOPS (input/output operations), with the rest taken care of by Azure.
WordPress: WordPress provides an online platform with white-labeled solutions, customization, and multiple integrations for its customers. Moreover, it collects customer usage data and charges on that bases.
Why is it important to pick the right SaaS type?
This is a common question. Let me explain why with two different examples.
Example 1
A company introduces isolated application VMs (virtual machines) for all its customers. In the majority of cases, these boxes will remain underutilized. If customers pay only for utilization, the company could end up with huge losses.
Example 2
All customers share the database servers and application servers and pay only for utilization. With this model, all of the hardware and automation are being properly utilized. However, a sudden increase in server utilization by one customer can trigger performance issues and unexpected breakdowns for others.
When a company starts building a SaaS application, it bears the hardware and automation costs. Therefore, picking the right SaaS architecture aligned with your offerings is crucial to optimize the above-mentioned costs. Damage control is still possible in the above examples, but you will still lose time and opportunities.
What are the different architecture types of SaaS applications?
Type 4 (Doesn’t require data and runtime isolation)
This is the most basic type of SaaS application. In this type, you assume that all of your customers will grow uniformly and create customer IDs accordingly. These customer IDs are added to all of the tables/collections and all customers share the database and application hardware.
Type 3 (Requires data isolation but no runtime isolation)
This is one-step advanced as compared to type 4. Different data stores are put in place for different customers of this type. However, the application is shared by all the customers.
Type 2 (Requires data and runtime isolation on the cloud)
This type involves separate applications and separate data stores for all customers. In this case, the cost of isolation is typically passed on to the customers.
Type 1 (Requires data and runtime isolation, but not on the cloud)
This type is a version of type 2 wherein the customer wants data to be stored on their network, not on the cloud. Herein, the customer still opts for pay-as-you-go or a pricing model that’s based on users/features as per onboarding.
How to pick the right SaaS type for your product
Depending on the type of industry and nature of the data, a customer’s requirement for security and shareability will vary. A company can anticipate the needs of multiple customers and can refer to the flowchart below to help select the right SaaS architecture type.
On a final note
In conclusion, as the product matures, molding existing architectures to accommodate demands from the growing user base becomes difficult. Therefore, it’s best to choose the right SaaS architecture at the start so that you don’t lose out on business because of rigidity.
Comment