h1

True SaaS, or half-baked SaaS?

March 15, 2010

And why does it matter?

Bloggers, industry analysis and developers have been confusing customers with their claims of  ‘belonging’ to the groundswell of On-Demand computing, or Software-as-a-Service.

Let’s be clear: if your vendor offers a true on-demand application but in parallel also offers an on-premise product, they are not true SaaS.

This matters – here’s why:

  • multiple product versions means multiple code tree. Means multiply your support, training, dec services, marketing and  operational logstics by n, where n = number of parallel offerings.
  • this results in greater inertia in bug fixes, enhancements, product roadmap and customer responsiveness. which results in alonger wait for good stuff to reach customers
  • If you’re smaller than Oracle/SAP/Microsoft and co, then you can’t afford to maintain multiple product offerings. The non-saas versions will drag you down, you’ll never get to market ahead of your pure-saas competitors.
  • as a customer of a non-pure-saas offering, you don’t get the benefits automatically – sales reps try to steer you toward their on-premise offering, as they will make so much more commission on that sales vs. monthly subscriptions

Here’s a checklist you should ask every application vendor you’re considering for implementation:

  1. do they have one instance only, with all customers sharing an identical image of the code, data schemas, sharing all datacenter resources equally? NO? A true saas provider may provide a choice of upgrade dates for customers, but hese are simply virtual segmentations of the same code base, with a logical grouping a, b, and c. That’s different from single tenant offerings, which allow companies to stay on a version as long as they like, and to upgrade in their own time. Why does this matter? Your vendor’s support resources will be diluted beyond the curent version of the app, needing to support stragglers, hybrids and “stuck in time” customers. Bad for you – you need to evolve and stay current.
  2. do they release minnimum 3x major releases a year? No? Dude – this is not the 90’s anymore. Companies have to stay current with new features, bug fixes,and new ideas. Imagine walking around with your 2007 iPhone…. Upgrades have to be quick, easy, effortless and free. Anything less, your vendor is not true SaaS. End of story.
  3. do they persist field names, objects, API versions, forever? This matters because if they deprecate a field, you might be using it in a report, API call or other web service. When you come in Monday morning, your stuff is broken, and it wasn’t you fault – your SaaS vendor broke it. This is bad manners – tell them not to do that anymore.
  4. do they offer development resources that allow you to customize, build, integrate and maintainwithout any moving parts in your building / datacenter? If you have to build libraries of API objects locally, or store mapping tables and transformation rules in a software appliance that lives “somewhere” not inside your vendor’s cloud, then somebody has missed the point. Go talk to them about their competitors.
  5. do they price their products with zero lock-in? You should expect to pay the same amount every month, regardless of how much or little your usage is. Unless you upgrade/downgrade from the pricing band that you’re agreed in, there is no change, month on month. Beware of fakes, who try to charge you on actual usage, or by colume of data stored. Why does this matter? SaaS belief system says the customer’s costs are predictable, stable, and fair. IT budgets no longer need to run over or be padded for worst case scenario. Also, vendors know their projected revenues ahead of time – everyone enjoys a new and improved predictability in costs and revenues.
  6. do they listen to their customers? Ah-Ha! The old school believed the software vendor knows best, so they design a best practices framework and build alot of software around the best practices. Thenthey realize they forgot about your specia needs so they built expensive customizations to handle those needs – and you paid them for that? Better idea: vendor, don’t build concrete walls; build rubber traffic cones instead. Get out of the way – let customers define their own restrictions and rules and validations. And for feature roadmaps, get out of the bpoardroom and into the blogosphere – your cuswtomers are tweeting – right now – about what would be nice to have in your next release. Oh by the way: your competitors are reading those tweets – wakey wakey…

Ok – if you didn’t already know all of this, you probably have a motorola razor and you keep paper maps in your car. But it’s OK, welcome aboard – we’re all loving this new landscape.

Advertisements

2 comments

  1. One of the hilarious things that has come about with cloud computing and the advent of large scale SaaS is that I’m seeing the same kinds of arguments I saw back in the dot-com days, that this is a fundamentally different business model that doesn’t obey the same rules as traditional software development. Which, of course, is utter nonsense. The method of delivery to customers has changed, but customers remain customers.

    I have a longer post on my own blog, but in brief:

    1. Multiple product versions are not necessary to have both a SaaS and non-SaaS version of a product. LAMP is LAMP, whether it is sold as a service or as a set of RPM packages to install on RHEL5.
    2. Any vendor whose sales commission structure pushes non-SaaS versions of the product is an idiot. SaaS requires far less support on our part.
    3. I have never — *ever* — met a customer that wanted rapid software version releases. Indeed, the biggest thing that customers have told me in my fifteen years of dealing with customers is that they want new releases far in advance of deployment in order to validate that the new release meets their needs and train their personnel on how to use the new release, which invariably means supporting at least two releases (the new release, and the previous version). There is a *reason* why the most-often-used version of Linux found in the wild is the 3-year-old Red Hat Enterprise Linux 5, *not* the latest Ubuntu or Fedora. Forcing customers to death march to new versions two or three times per year is how you lose customers.
    4. Software designed by tweets is software designed by twits. 160 characters simply isn’t enough to find out what customers really want (as vs. what they vaguely think they want).
    5. My phone is an iPhone and the only paper maps in my car are 1:24000 USGS topographical maps, where there is no acceptable equivalent available for portable GPS units. Just sayin’ :).

    I’ve seen no sign that customers have changed just because the mechanism of delivering software to them has changed. Human nature remains human nature, in its pure ornery glory. Young engineers tend to take customers at face value, then not understand why the customer rejects the result as not meeting his needs. I get called conservative sometimes because I call for slowing down release cycles, maintaining backward compatibility wherever feasible, extensive trials with customers to validate that the new release meets their needs, etc., but my experience is that this is what customers want — as vs. what they say they want, which is something else entirely.


  2. I agree with Eric Green. Customers always want choice. I’ve take a more middle-of-the-road position on my blog. http://wp.me/pMfBc-1o. There are pros and cons to pure and hybrid SaaS.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: