True SaaS, or half-baked SaaS?

7 min read

And why does it matter?

Bloggers, industry nalysis and developers have been confusing customers with their claims of adherence and 'belonging' to the groundswell movement 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 parallelofferings.
  • 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 subscriptio

Here is 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.