When the Workday sales team met at headquarters last week to kick off the second half of a fantastic year, one of the topics we discussed was how team members should differentiate Workday’s SaaS from competitors’ “SaaS options” for on-premise software.
There’s a big difference between products written for SaaS, and legacy software that’s been Frankensteined into what some software companies are trying to pass off as SaaS. I wanted to help the sales team explain this to others without having to jump into technical discussions about “multi-tenant” architectures.
In a quick presentation to the team, I explained that real SaaS includes these attributes:
Coincidentally, I came into work a few days later and happened across this blog at the Web site SystematicHR.com, titled “Defining SaaS.” SystematicHR.com had an even simpler definition:
I think simple is always better, so I like SystematicHR’s definition quite a bit – especially point No. 2. It calls out the primary reason why real SaaS is much more than just hosting, and why there’s a higher bar for vendors wanting to offer real SaaS.
Keeping customers on the same version of a single codebase requires the vendor to own and manage all updates to that codebase. Updating code and converting customer data is its responsibility, not its customers. A real SaaS vendor includes those updates as part of the regular subscription price.
Legacy vendors don’t go all the way to real SaaS. They will host the software for an additional fee (above and beyond the software license fee) and will help update an individual customer’s implementation–when that customer is ready to pay them extra to do it. There should be some kind of label for this type of hosting, but it isn’t SaaS.
When vendors go the extra mile to keep all of their customers together on a single codebase, customers benefit from lower cost maintenance and updates, more frequent updates (faster time to innovation), and closer partnerships with their vendors.
These real SaaS vendors benefit, too. A single codebase means they maintain fewer versions of the software. They spend less time on technical documentation and training to help customers maintain and update code that the vendors have written, and vendors plan for the core product just once (rather than the legacy approach, which calls for months of strategy around a single monolithic software upgrade).
SaaS vendors can afford to do all this work, and include it as part of the base subscription, because of multi-tenant architectures. Legacy software vendors would do these things if their legacy architectures allowed it, but they don’t.
In a world where everyone is claiming to be “in the cloud,” I’d like to see our sales team use this simple definition—hosted + single codebase–to prevent the competition from oversimplifying the value of SaaS.