SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

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:

  1. 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.”
  2. Security and inappropriate data access.
  3. Impact of other clients on their system performance.
  4. Inability to establish and pay for their own, higher service levels (common among large companies).
  5. Being forced into an upgrade.
  6. Inability to support the level of client specific configurations and even customizations as necessary.
  7. Inability to obtain client level user acceptance testing
  8. 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.

Related Articles

Lack of Good Platforms is Stunting SaaS and Business Web 2.0:  Discusses customization and SaaS.

SaaS, Mashups, and Web Software:  The Rub is Customization

2 Responses to “Virtualization vs Multitenancy at Workstream: SaaS Quandry?”

  1. ilyabm said

    Hardware virtualization, with single-digit real-life consolidation ratio, will probably not be good enough in most cases. But a light-weight server virtualization technology – like Virtuozzo ( that can host 100+ virtual environments on a single server – provides very cost-effective solution. Even if an ISV is very determined to pursue multi-tenancy, virtualization will buy you enough time to make the transition smooth and successful. However, in the majority of cases, further transition might not be even necessary. More on that at

  2. perpetapaul said

    Customization is the Achilles Heel of a multi-tenant Saas offering. We run a system that involves 2 of the largest clients in our market, with over 12,000 seats between them, and they both thought that they wanted everything customized.

    But the key to our success with all clients, large and small, is to listen to what they are saying, ask questions and determine what they are trying to accomplish. We find in 80%+ of the cases, the clients are really asking for the same thing, but in different ways or with different configuration options.

    We then design, build and roll-out our updates, to all clients, so that they all get what they want. It is not easy, but it is the only way to keep from having to build custom processes that will become maintenance headaches as your systems evolve.

    Our multi-tenant, SaaS offerings have been up and running for more than 2 years now and we add more clients each month. Our clients’ employees depend on our system to schedule their work, complete it and report on it – including their timekeeping, so it is important that we get it right.

    Anyone who believes that you have to customize for your larger clients has not done their homework or been able to sell their clients on the benefits of making configurable systems. Only those organizations that figure out how to do this well will survive and thrive as true multi-tenant, non-customized SaaS offerings.


%d bloggers like this: