Virtualization vs Multitenancy at Workstream: SaaS Quandry?
Posted by Bob Warfield on October 20, 2007
Phil Wainewright has just posted about SaaS vendor Workstream’s choice to offer virtualized single instances to large customers instead of multitenancy. Workstream gave him a collection of reasons for the choice:
- Customization for large customers requires separate instances. Workstream say, “clients have a need for system changes to match key cycles — like their pay for performance cycles. As a result, there is a demand for more tightly controlled, client-unique system changes.”
- Security and inappropriate data access.
- Impact of other clients on their system performance.
- Inability to establish and pay for their own, higher service levels (common among large companies).
- Being forced into an upgrade.
- Inability to support the level of client specific configurations and even customizations as necessary.
- Inability to obtain client level user acceptance testing
- Inability to determine the precise production/go live dates for the system.
Wainewright awards equal merit to all 8 reasons, and because of that, concludes that customization is just a small piece of the puzzle. I think there’s room to examine customization more deeply, so I dug out the company’s 10K and found some interesting data. Their professional services revenue, which the 10K defines “from implementation of software applications and from customer training, customization and general consulting”, is about half their SaaS revenue. Neither is very large, by the way.
I find that professional services number to be worrisome, because it says customers are spending a huge amount to customize the system. When you look at how the revenue recognition works for SaaS, the professional services are even more out of whack. The reason is that some amount of the SaaS revenue, perhaps even the lion’s share, is for systems that are already up and running. The professional services are largely only applicable to installing and customizing new systems. This implies a very large up-front customization engagement is necessary to get this SaaS application going. Professional Services might be several times the annual SaaS contract value here.
More power to these guys for having a SaaS offering, and I totally understand that large organizations (and especially their government and education customers) can be very dictatorial. But I think we can miss an important issue if we sweep all that under the rug of the remaining objections. Looking at those remaining objections, 2 through 7 are classic objections to SaaS. Every SaaS vendor deals with them, and many, such as Concur who has one customer with 180,000 seats, are able to do business with large enterprises despite the objections. Workstream wants to be able to say “yes” to customers no matter what, and that’s fine too, but there is a cost to it in terms of losing a lot of SaaS benefits along the way. The 8th reason I can’t fathom at all. An “inability to determine precise go-live dates” smacks again of the customization theme.
The point I come to on this is that I don’t see Workstream as presenting a virtualization quandry for SaaS vendors so much as it underscores the customization quandry in my mind. For SaaS to work well, it needs to be self-service from the customer’s perspective. Big professional services engagements add a lot of friction to the SaaS machine. It’s my contention that solving the customization conundrum for a particular segment that requires it is probably a more strategic issue than whether to go virtual or multitenant. It has to be possible to do all the customization needed with the following qualities:
- It’s approachable by non-technical users
- It involves metadata, not code changes, and the metadata can run in a multitenant single-instance world without disturbing other tenants.
- The work to configure a new customer is a tiny fraction of the annual SaaS contract even if you farm the work out to consultants.
This can be done even for extremely complex domains. Sales compensation is a field I’m very familiar with and business logic there is Byzantine. Yet, SaaS vendor Xactly does an implementation with about 6 weeks of inexpensive consulting, and the whole thing runs multitenant.
There’s been huge focus on multitenancy as the defining technology behind SaaS, and as a technological barrier to would-be SaaS vendors. Workstream is a great example of why for many domains there is a big elephant called customization sitting in the room that nobody wants to talk about.
Lack of Good Platforms is Stunting SaaS and Business Web 2.0: Discusses customization and SaaS.