In the beginning, the problem facing Software-as-a-Service offerings was that they weren’t software. At least not in the traditional, on-premise sense that customers were accustomed to. To compete, then, as is often the case, SaaS had to become that which it competed with. Which meant that, fundamentally different delivery model or no, SaaS companies grew to resemble the software companies they were competing with, and in some cases, replacing. Everything from sales models (multi-year contracts) to the people hired away from on-premise software vendors by SaaS alternatives reinforced this idea, which to varying extents persists in SaaS companies to this day.
None of this is surprising, or in most cases, problematic. It was, after all, an adaptation to a market, one driven in large part by customer expectations. It does mean that SaaS companies have curious blind spots, however. So conditioned have they been to think and sell like the on-premise products they compete with that they’ve almost forgotten that they’re not on-premise themselves. The most obvious example of this at work is one that we’ve been discussing with our SaaS clients more and more of late.
Consider the enterprise IT landscape today. At virtually every level of infrastructure, there exist multiple, credible freely available open source options to pick from. From the VM to the container to the operating system to the scheduler to the database, choice abounds. Many of these were solutions first and products second, which means that while there may be rough edges, they have in many cases been proven to work at a scale that an average customer will never experience. Time was you had to have “bakeoffs” between competing commercial products to see if they would handle your transaction volume. These days, unless you handle more traffic than the likes of Facebook, Google or Twitter, that’s probably not necessary.
This is a remarkable achievement for an industry that at one time was dominated by expensive, functionally limited products that might or not work for a given project but guaranteed a poor developer experience. It is an achievement that has not come without a cost, however, and that cost is choice.
As has been documented in this space multiple times, the increasing volume of high quality open source software is bringing with it unintended consequences, among them lengthier and more challenging evaluations. As much as organizations didn’t appreciate only being able to choose from a small handful of expensive application servers, that was an approachable, manageable choice. There was one model and two or three vendors.
Today, there are many models to choose from, and thus many choices to be made. Public or private infrastructure. If it’s private, what does the infrastructure consist of? OpenStack? Cloud Foundry? Kubernetes? Mesos? What is the appropriate atomic unit of computing? VM? Container? App?
For organizations that are both capable and view their technical infrastructure as a competitive edge, this is a golden age. Never before has so much high quality engineering – tech that would been unimaginably expensive even a decade ago – been available at no cost. And free to modify.
This does not, however, describe most organizations. By and large enterprises are doing well today to merely keep their heads above water with a well thought out and accepted public versus private infrastructure strategy, never mind all of the other choices that follow from there.
Which brings us back to the businesses offering SaaS solutions. When they brief us, they spend the majority of their time talking about their engineering, their usability, their sales, their partners, their pedigree and so on. They discuss not at all, in general, the biggest potential differentiator they have: the absence of choice.
This again is understandable: very few vendors want to go to market saying “no more choices for you.” But the time is coming, quickly, when this might be exactly the right message. If you have a hosted application platform, for example, do you really want to get bogged down in a feature comparison between an on-premise alternative? Or would you prefer to call attention to the fact that all of the evaluation that goes into determining which of the Container/OpenStack/Cloud Foundry/Kubernetes/Mesos cabal to use and how they can be fit together no longer needs to occur? That the idea of having an application idea in the morning and deploying it in the afternoon is actually realistic because the infrastructure has already been assembled?
There are counters to this argument, clearly. If I’m an on-premise provider, I’d be making a lot of noise about “noisy neighbors,” large scale outages (because enterprises rarely have the internal numbers to know how they compare) and so on. But I’d be making a lot of noise because deep down I’d understand that, paradoxically, SaaS’s removal of choice is advantage that looks more compelling by the day. Which is why I tell all of our SaaS clients to articulate not only what they offer, but the technology that clients no longer have to evaluate, test and deploy as a result of going with a service, because that is a fundamental value they offer.
They just forget that at times, which happens when you’re used to competing head to head with on-premise every day.
