What makes a “true” SaaS Company?
Last night, my wife and I went to a movie at this spanking new mall in Malleswaram. One of the best food courts I’ve seen (Huh? But you went to a movie, you say? But of course! How can you see a movie without pigging out?!), very airy, lots of varieties of food, nice little umbrellas on tables – and lots of tables piled high with trash. I am not kidding – by 2100, over 90% of the 100-odd tables had uncleared trash. People were walking around with trays laden with food, desperately trying to find a table that was clean. The airyness was overwhelmed by the smell of regurgitated chicken from this American brand that seems to have no real reason for its popularity in spice-laden India. And there I was, thinking: “Hmm, this looks like an in-premise sale.”
I have to admit that, like the old Vedic Masters who see God in everything around them, I see SaaS issues everywhere. The realtor that built the Mall spent tons of money, the architect put huge effort into it, so much marketing went into getting us in there – all to naught. Because the cleaners had not been efficient enough to clear trash. Because some of the users of the Mall had no idea how to take out their own trash anyway. Much like a user of an in-premise solution where the local IT team did not have the same lofty objectives as the software designer.
But really, these factors about why SaaS scores over In-premise are very well documented on the Web. Very simply, we agonize over Usage, while In-premise software companies agonize over Sales. Over the last few days, though, I’ve been in a series of discussions not about how SaaS is different from In-premise but about how some SaaS companies differ from other SaaS companies. The discussions were triggered by an excellent piece by Brian Sommer in ZDNet, about what he calls a “SaaS-querade” of vendors. All this online and offline talk has egged me into putting a stake in (no, not the hearts of some of the speakers!) the ground, about what I think SaaS is GOING TO BE all about.
For those who came in late (a la Phantom comics), SaaS stands for “Software-as-a-Service”, where you buy and use fairly complicated software completely on the Web. The most direct benefits are fairly clear – no CapEx on the customer’s part, low up-front cost delivering high value immediately, tremendous ease of implementation and so on. But I think this is just the beginning – the “true” value of SaaS is only just beginning to be recognized. IMHO, over time, there are a few other benefits that some SaaS vendors will deliver – and those are the ones that will grow well. Here they are.
- The first, most important value a good SaaS company will deliver is constantly-increasing value via seamless upgrades. That’s a mouthful, so let me explain. With Impel, every four weeks or so, customers see some minor, some major enhancements that they can choose to use. The upgrades are non-intrusive in that they won’t get in the way of what you’re used to doing with Impel, but they usually will give you a better way of doing that. Or they will give you a whole new “thing” you can do. For example, we have this ability to send and receive email from within Impel. Emails sent to and received from a Contact are tagged with that Contact record, so anyone reviewing that Contact can see them in the context of any other Activities you may have had with that Contact – phone calls, meetings, etc. That’s just a new tab – and you can choose not to enable it. So a very powerful new feature just appears magically – and you can choose to make it go away it if you don’t need it. The point here is not about how well the tech is done but about the fact that the functional breadth and depth of your subscription keeps growing over time. It’s like buying a Tata Ace for your transport business and that magically turning into a Tata LPS 4923 as your business grows.
- A true SaaS company will deliver uptime and reliability as a life-and-death issue – for them, not just for their customers. They’ll do this via something called “multi-tenancy”. Multi-tenancy is tech-speak for a system where we run ONE large “instance” of software for ALL our customers. So whether a user from large consumer goods manufacturer with hundreds of users is logging in or someone with two salespeople in Jhumritalaiya, they access the SAME software (with a bunch of fail-over background servers, of course). Now, why is that important to you as a user, apart from a vague sense of democracy? I’ll explain: implemented as a core element of our software, this means that the software has to be up and effective for EVERY user of the system, not just for a few customers. So there’s no way I can tell one customer that hey, OK, your software is down and someone is working on it; if your software is down, so is everyone else’s. And I am being beaten on by EVERY customer by the minute. In comparison to a non-multi-tenant model where each customer gets a separate instance, the multi-tenant model now moves Uptime from a Nice-to-have to a Critical-for-business issue for me, the vendor. That means we do whatever it takes to keep our software running and responding in seconds, something companies with other delivery models are not incentivised to do.
If you’re a devious thinker like me, I’m sure you’re going: “OK, so if all this puts so much pressure on you, why are you, my dear fellow, putting so much effort into building this thing called multi-whatever?” I’ll tell you: because, without multi-tenancy, it would be Hell to roll out those upgrades I speak of above. Clearly, it is cheaper for us to run that ONE instance for hundreds of users than to run multiple instances for different customers, if we have to provide that continuing value enhancement. So there you have it: multi-tenancy is better for you and cheaper for us – a marriage made in Heaven!
- Now that I’ve made such a big case for multi-tenancy, let me go further and say that’s not enough (hmm, now why does that sound like an issue in some marriages, too?). SaaS companies will need to support separate, identical databases what’s called “mega-tenancy” also. This is tech-speak for a way in which, while there’s still just one large instance of our software, we can give you your own database in our network. That puts full-scale back-end IT infrastructure in place for you – you can now get full back-ups of your data, peel them off to a CD, put them in remote storage for compliance, scratch that paranoid itch about commingling data, whatever. Of course, an In-premise vendor will immediately jump up and say “We can do that too!” Of course they can, but without the other advantages of SaaS, I am only reminded of that smart-alec line: “Apart from that, Mrs. Lincoln, how was the play?”
- The fourth and biggest value of “true SaaS” is Customization, something most SaaS vendors shy away from currently in very innovative ways. For example, one of our competitors has a large set of Wiki entries titles “Customizing <bleep> CRM”. That’s terrific – till you read what’s in there. It’s a bunch of Configuration instructions – stuff that you can do on your own. Ask them if they can change a call-center workflow for them and they’ll hum and haw. That’s because, I think, of the WAY these apps have been built. Being Circa 2000 apps, their support of multi-tenancy is an early architecture, not planning for handing custom functions for some users. With the advent of newer development platforms that natively support multi-tenancy, Customization becomes as easy as Configuration. And with the integration of an in-house development team that takes full responsibility for that customization, the SaaS company now becomes truly responsive to everything that your business needs as it grows and changes. This is particularly important in a growing marketplace like India, where our customers are constantly trying new, innovative ways to reach out to their customers. They constantly need changes to the way Impel works – and we make those changes. Most SaaS technologies will tell you that that’s just not possible in a multi-tenant model – we’ll tell you it is. That’s not because we’ve done anything dramatically Earth-shaking in our design – we’ve just architected Impel in a manner where we do support deep Customization, apart from a high degree of Configuration, in our single instance-multiple-database offering.
From a tech-architecture stand-point (non-techies can stop reading now), there are a number of descriptions on the web that talk of similar things. One of the clearest I’ve seen is Kunal Mittal’s description, taking you from the non-SaaS world to a Maturity Model 4. IMHO, there’s at least a Maturity Model 5 coming – one that supports items 3 and 4 above. Kunal probably sees that already!
So there’s the extent of my crystal-ball-gazing, albeit somewhat tainted by our own software design. Now, if I can tell you how the Mall business will grow, I could well have a chance to apprentice with Donald Trump himself!
