SaaS is hard, but rewarding

From an Engineering and Product Perspective…what makes SaaS applications so different from traditional software applications? Let me count the ways…

1. Provisioning. The SaaS approach lowers the barrier and makes it so that you don’t have to buy and install anything from software to hardware to get the benefits of the application. With a SaaS system the customer can dream up whatever they want and get it quickly and easily from the system. From a SaaS ISV perspective, it means that the provisioning must be built to easily turn on new customers and not implement a bunch of new hardware or software to do it, you can create the account, the customer access, and they can get started…in fact, it is even better when the whole implementation process is automated. It must be done in an automated way; otherwise the economics of implementing new customers with lots of people don’t work.

2. The Application: SaaS means that the application is the same for everyone; they aren’t independent implementations that are unique for each customer. However, because every customer needs a unique set of features and tailored customized functionality, the single set of applications needs to be built to be flexible enough to allow for each customer to leverage the same application servers without modification but yet tailored and customized for their specific implementation. Permissions need to allow for customers to use sub-sets of the functionality as well based on what they have purchased, so that a single application can be virtually delivered as multiple tiers of products based on customer needs. The application services also need to scale in a much bigger way. Because this is a single implementation, it will have a much greater usage since so many people are using it and it is being utilized to much greater degree than in traditional implementations where there is so much excess bandwidth and cpu because systems are used privately. SaaS vendors don’t just create an application that is mastered on CD…but they are building and maintaining a live system that is constantly being used and updated at the same time. Most SaaS ISV’s have multiple sets of these application servers set up to move their dynamic applications through the process of testing and finally into the live production servers that the customer actually sees. There is a lot of investment there.

3. The Database: SaaS means that the database is also set up in a way that allows for a large scale deployment that is bigger than a traditional private implementation and since the data exists in this massive database infrastructure, the data must have the appropriate security and permissions among not just individual customers, but also the user permissions and roles within a customer based on the functionality that they are buying from the service. SaaS ISV’s don’t just have database driven applications…they are experts in large scale database implementations with all the security, uptime, and replication issues that come along with it.

4. The Connectivity: The users must be able to get in and out of the systems that are now located remotely. That connectivity will need to scale and be highly available since it is shared. Private connectivity isn’t usually a problem and is “free” since they are leveraging the private networks within the office. However, when you reach out and do a significant amount of work across a WAN, that bandwidth isn’t free and you will be buying more of it than you have had to in the past. SaaS ISV’s are not just experts in their application, but they are also experts in networking and connectivity.

5. The Performance: The users expect the system to perform with perfection…very little tolerance for failures or downtime. Now you would probably think that is true for non-SaaS applications, and it is true. However, the difference is that the performance of software application running on a computer has a luxurious amount of CPU, memory, and disk space that is nicely dedicated to just the single set of eyeballs sitting in front of it. On a SaaS system, the performance has many more variables involved with the same or better performance expectations. Other variables include the connectivity the local network, the connectivity over the wan, internet performance, cpu and memory and i/o of the multi-tenant system being used by other people at the same time in a datacenter that is who know how many miles away. These are all considerations that are built into SaaS applications.

6. Collaboration: When you have installed an application on your computer and it is doing what you want…how do you use that application and its output to collaborate with other people? Some people argue that some software activities are an individual exercise and don’t require collaboration. They are wrong. It is shocking to find out what new value is created by innovating around collaboration. The collaboration doesn’t have to be always real-time, but it should require anything special to allow multiple people to participate together in whatever activity you can dream of in the virtual world. SaaS applications are best suited for this collaborative activity and the innovation that exists out there are still immense.

Not every software company can make the leap to SaaS. Not because they don’t want to, but because it is a different way to develop and deliver software that requires a much greater investment in areas that are not traditionally strengths of an ISV. When software companies can invest in the equipment, connectivity, multi-tenant architectures, and collaborative innovations…then they have a shot at successfully playing ball in SaaS.