I remember the first time I encountered the term “Software as a Service,” and it was longer ago than you might think. I was running a red-hot ASP start-up in Houston called ebaseOne. We’d taken a tiny local software VAR, changed the name, secured investment capital, hired some infrastructure experts, built a state of the art operations center, signed a co-location deal for a brand new leading-edge data center and leveraged the existing staff’s application expertise to start offering application access to customers for a single, monthly per-user subscription fee with almost no cost up front. We didn’t develop software – we just hosted a variety of products, on the assumption that customers wouldn’t want to deal with hundreds of vendors for their software subscription needs – they’d want a one-stop shop that they could get all their applications from. For products that weren’t web-based, we used technologies from Citrix and Marimba to distribute updates and manage the customer desktop. Cisco, among other partners, thought we were visionaries. A year after we started we’d gone through a few million bucks in funding, but our market capitalization was over a half billion. Then the internet bubble burst at exactly the wrong moment, and the next round of funding never came. Ouch.
We weren’t the only ones. Another ASP getting attention at that time was US Internetworking, or USi for short. If memory serves, at some point while we were ramping up, USi came up with a brilliant tag-line: Software as a Service. It wasn’t a trademark or anything – just a term they started using when speaking to investors. We started using it too. So did another little company that called itself an ASP at the time but developed its own software: Salesforce.Com. This was in 1999, long before cloud computing (it wasn’t until the end of 2004 that AWS was even available for public use, and it didn’t really catch fire until much later in the decade).
When cloud did first begin getting everyone’s attention there was a lot of head-scratching about the actual definition of it. Many people just thought it was a way to rent virtualized servers. The consulting firm I went to after my start-up looked to me for a definition in 2010. Among other things, I told them this about SaaS: “SaaS can be delivered via cloud computing, but it does not have to be.” And that was true. All you needed to do for the SaaS label to apply to your service was to host applications and charge for access per user per month instead of selling licenses. To a great extent, and to my complete surprise, that is still true today. Now I’m going to talk about why.
Shortly after that, much of what I had said about SaaS became irrelevant. NIST had published their official definition, and the industry adopted it pervasively. In that definition, SaaS was defined as one of the three cloud service models (IaaS, PaaS and SaaS). The uncomfortable fact that SaaS had already existed for a long time and that many offerings were not very cloud-like was simply ignored. SaaS was now cloud, by definition, and all SaaS vendors instantly became Cloud Service Providers, without so much as a “hey, wait a minute.” Customers and pundits could have asked if SaaS services even sat on top of elastic cloud infrastructure, but they didn’t. A lot of SaaS applications still don’t. I believe it is this de facto SaaS = cloud equivalence that has distracted customers from what could really be achieved if the cloud model were fully applied to application services.
A big thing that SaaS products don’t offer today, but could, is real usage-based pricing. Every SaaS provider will tell you that “you pay only for what you use,” because you only pay for the users that are allowed to use software. Time to take the red pill, Neo. That’s really all you were paying for before cloud came along, and it’s called user-based pricing. What happens when a user is out sick and not using the software? Oh yeah, you still pay. SaaS providers offer the same thing today that software companies have been offering as long as I can remember: an up-front fee followed by a periodic fee for updates and support. Sure, your IT folks don’t have to do the upgrades – yay – but financially the only difference is that the bill has changed to monthly instead of annual, if you’re lucky. Many SaaS customers find that signing a deal will still lock them into a multi-year commitment for a certain minimum number of users. That’s nothing new, and it’s in complete opposition to one of the basic philosophies of cloud, which is to pay only for use.
Now, if SaaS services were to measure minutes (or seconds) of the time someone actually has the app active on their desktop and billed you based on that, we would really have something different. The number of users wouldn’t be directly relevant, and you really would be paying only for what you used. If your users started using the software less and less, your bill would automatically decrease in step with that. No more need for closely managing the software portfolio to make sure you aren’t over-licensed. Wouldn’t that be great? I think it would. Over-licensing due to shelf-ware and functional duplication between products can represent millions of dollars in annual software costs for a large enterprise. Start-ups could start out with enterprise level apps and not worry about their solutions hitting a scalability wall. Enterprises heading into a downturn wouldn’t be stuck paying for software they don’t need since charges would go down in lock-step with usage. This is what I call “pay as you grow / save as you shrink.” Want to migrate away from a product and replace it with a different one? Just stop using it whenever you’re ready.
And the data from metering could eventually be used in all kinds of constructive ways. You could see how a change in features, functions, processes, staff, work environment, etc. affect time spent in the application, for example. You could see changes in usage patterns in near real-time and investigate root causes. Of course, you’d need to keep pressure on your provider to make sure that changes to the application didn’t lower productivity, thus increasing their revenue, but that’s all part of the evaluation.
We didn’t implement true usage-based pricing at ebaseOne, but we were working on it. We invested in the high-end monitoring and billing systems we would need to bill our customers for minutes of usage, got them up and running and did the training. This is similar to what long-distance phone companies once did in order to bill for phone calls. Many SaaS providers today don’t have all the required systems in place yet, but only because they don’t need to. They don’t relish the idea of an unpredictable revenue stream, where there are no financial barriers keeping their customers from switching to the competition. If they’re public they have to set expectations for the street every quarter and then meet those expectations, so predictability is good. And yet, Amazon is in exactly the same situation with the on-demand services in AWS, and they’re doing just fine.
The real reason that SaaS providers haven’t offered this is that the market has not demanded it. Yet. Software companies don’t like change and will have to be forced into it by competition. Start-ups – this is your opportunity.