We are pleased to welcome guest blogger Dani Shomron, a SAAS industry veteran. Dani has held development, management and executive roles in multiple verticles and geographies. He holds a BSc. in Computer Science from the Hebrew University and an MSc. in Artificial Intelligence from the University of Edinburgh. Dani is an expert in SaaS Operations and ISVs transition from on-site to on-demand.
If I had a great idea for the next killer app (I have, actually) and if I had unlimited funds (I don’t, actually) I would have built the software as an on-demand offering.
I would have spent half my funds on building the operational support systems – provisioning, billing, retention policy, self-service, report generator, etc. The other half would be invested in building instrumentation, redundancy, automation, integration, application level monitoring, silent upgrades, customer notifications, and so on.
The rest of the money (you may wonder about my math, but hey, I’ve got unlimited funds) would go towards building the actual application.
Most SaaS vendors out there (and they are growing fast) have chosen the predictable path of building the application first, and worrying about serviceability later. This is the fastest way of getting to market with low costs. The next step is choosing some viable hosting solution and off we go, offering the world our ever better CRM.
Many months and dozens of customers later, reality hits with all the issues of servicing the software, rapid growth and dealing with labor intensive tasks that are the humdrum of daily life in a SaaS operation. Provisioning/de-provisioning, configuration changes, customized reports, and the most dreaded – upgrades, task the team as a whole, especially when the product is successful and the number of customers is growing daily.
It is not that SaaS executives, architects and engineers are lacking in any way. On the contrary, they are mostly smart, inventive, and creative and have a deep understanding of their customers’ needs in the specific domain. The problem is that they are product people, not service people. Practically none of them come from IT and cannot envision the life of a service operations engineer.
At this point, automation becomes crucial to the survival of the business.
Whether it is built into the next version (many architectures make this quite difficult) or done externally, automation is needed to reduce costs, physical labor, frustration and mainly, error-prone manual procedures. Repeatability, which is a derivative of automation, is also crucial.
Automation is needed across the board. Be it in setting up a new server, or building a new application instance. It could be a manual procedure regarding provisioning of application resources, or building a seamless upgrade procedure.
Outages happen. How quickly can you recover from a service disruption and ensure that the recovery does not create it own problems? Automation not only provides the routines for quick recovery, but instills a discipline of thinking out the necessary steps, discovering dependencies and planning ahead. An added benefit of automation is that it documents the process so you can go back and review the best and worst of your procedures.
In my next post I will take a closer look at the SaaS Upgrade Nightmare.
Click here to read more about Automation and Delegation.
Tags: automation, SaaS, SaaS Operations
application service automation
Good article. Very few companies really think about this stuff early. I’ve been in engineering or product mgmt with 3 SaaS companies now. In fact, even as the VP of Product Development at the last company it was difficult to convince people that SaaS operations is important when you’re trying to get your product out. (something about not having unlimited funds) I now work with a company that provides this type of infrastructure to other SaaS services. Interestingly enough, we’re seeing more and more early stage companies speaking with us. Not long ago it was only larger SaaS services that had run head-on into the problem that were calling us.
You break the operations pieces up into 2 parts. I completely agree that the 2nd part is tightly coupled with the application and likely needs to be done in house. The 1st part (provisioning, billing, retention policy, self-service, report generator) exists today in the form of SaaS offerings that manage subscribers/billing/payments. There are some great services that give you all of this right out of the box. IPA’s platform is just one of them.
Very good article. Its very essential to understand the level of automation required when you build up your own SaaS company. Based on my own experience you should pay attention to your order & billing processes related automation too.
We spent 3 months building our SaaS offering front-end and another 6 on the provisioning, billing, retention policy, self-service, report generator, etc. It was very frustrating for the non-technical people in the business, as for the first 3 months they saw all sorts of lovely stuff popping up daily, then nothing. However now that we have all the automation done our app should run smoothly and with very little human involvement in the mundane tasks. It was a painful decision to approach it like this and cost us lots of money and time but Mr Shomron nails it on the head !