Salesforce is the premier provider of SaaS, and their stock recently took a hit because the Street didn’t like their guidance in their earnings call and their executive changes. The company has been a bit of a darling of the Street, as have most of the cloud companies, but unlike the major cloud providers, Salesforce is pretty much a pure play on the cloud. So what’s really going on? Do we have a Salesforce problem, a SaaS problem, or a cloud problem?
If you dig into public cloud services, you likely find terms that end in “aaS”, which of course means “as-a-service”. We have all sorts of aaSs (be careful how you pronounce that!) but one of them is SaaS, for “software-as-a-service”. I’ve not talked about this particular form of cloud computing as much because SaaS is an application set, not a general cloud resource, but there are some reasons we need to talk about it now.
As a cloud model, the advantages of SaaS are pretty clear. It presents users with an application and not just a resource, so it’s easy to establish a business case. You essentially subscribe to an online application, so there’s not as much (if any) development work associated with it. It’s ideal for organizations who want an application but don’t want to go through their IT organization to get it. There’s some administration needed, but it’s way easier than using cloud hosting in infrastructure- or platform-as-a-service mode.
There are also risks, of course. In theory, almost anything can be run in the cloud on IaaS/PaaS, and anything can be written to run there using all manner of custom tools and features. SaaS is an application set, so its breadth of utility depends on just how many applications are in the set and what feature flexibility is offered in each.
Do the pluses outweigh the minuses? Well, there’s one key minus we need to add, one that’s only implied, and that’s the fact that SaaS is outside the area of cloud services where the largest business driver of the cloud is focused.
Why do companies adopt cloud computing? The simple fact is that the great majority of public cloud services target the creation of an enhanced, broadened, user interface to company applications, what I’ve continually called a “front-end” to those applications. Companies started this because they wanted to open a direct online conduit to their customers, and have expanded their interest to include creating a partner connection and even to support their own workers. If you look at public cloud application development, this is almost a universal target, and SaaS doesn’t fit into it.
Could it? Companies like Salesforce, the market leader, certainly think that something could be done. Their SaaS tools already integrate with company data and applications, and they’re offering more general tools for integration as well. They offer at least some customer support and marketing applications too, but the enterprise contacts I have rarely mention them as candidates to support a cloud front-end mission. We need to explore why that is to answer the question of whether SaaS could fit.
A facet of the problem can be laid to a theme I’ve mentioned before, which is marketing and “trajectory management”. If you go to the website for Salesforce or another SaaS player, and if you play the role of a prospect who’s kicking the SaaS tires, it’s easy to see how you’d abandon your consideration quickly. It’s not easy to navigate the site from a position of ignorance about SaaS and the company’s offerings. If you wanted, or knew about, Salesforce offerings like CRM you could pick out what you need, but I took the time to play the role of an enterprise exploring whether there was a “SaaS front-end” tool, and came away with no answer. Salesforce and others in the space aren’t developing the demand for a SaaS front-end.
The “why” associated with that truth is another facet of the problem. Public cloud dependence on a hybrid cloud model where data center applications and databases are front-ended by cloud elements has been swept under the surface by the “everything moves to the cloud” theme. IBM recently gained traction in cloud applications because they at least understood what buyers were trying to do. In the last year, perhaps spurred in part by IBM’s traction, the three major cloud providers have stepped up their hybrid cloud story, but that hasn’t happened among the SaaS players.
And the “why” for that particular point is our last facet. SaaS is really application-as-a-service, and the front-end mission is not one that’s particularly easy for a company to adopt in “stock software” form. A cloud front-end has to be tightly integrated with the data center piece of the hybrid cloud, and also to the company website. That multi-dimensional integration requirement combines with the simple fact that the front-end element of applications is literally the face of the company to mean that companies are pretty particular with regard to how it looks and works. It’s my view that SaaS as a model isn’t helpful in the great majority of cloud front-end missions.
That doesn’t necessarily mean that SaaS-centric companies like Salesforce are cut out of the cloud bonanza. There are three possible ways they could get into the game.
The first way would be to go directly head to head with Amazon, Google, and Microsoft. That would mean a major amount of development, big changes in sales and marketing, and a major set of new risks, all to join a field that many think is already crowded. Non-starter.
The second way would be to develop what I’ll call a “front-end SaaS” model targeted to smaller-than-enterprise businesses. These companies are less likely to have a need for highly dynamic websites, and may already use site-building tools. The problem with this approach is that it targets prospects that would be harder to close through direct sales, and harder to support if you succeed. Possible.
The third way would be to develop a “front-end-PaaS” instead. It might be possible to build a platform that would facilitate hybrid cloud front-end implementation without unduly constraining it. I stress “might” here because nobody has really tried to do that. If I’m correct in presuming that the general trend in hybrid cloud has been obscured until recently, then the nature of a specific model for cloud front-ending has also been obscured. Right now, organizations build their own model from more primitive tools, offered as web services by public cloud providers, and Amazon’s extensions to AWS suggest that the big cloud providers may be enhancing those tools. Many of the changes Amazon recently announced deal with integration, noting that having service features created by semi-autonomous product units can create something only an architect can understand and assemble. Are they backing into PaaS?
A broader question is whether a general PaaS be defined that would make development easier and faster, and offer enough flexibility to accommodate the different visions of the GUI that inevitably emerge in a competitive market. Maybe. Some constraint is inevitable in a PaaS model because platform features, to facilitate development, must presume something about the direction development will take. So the real question is whether it’s possible to develop a PaaS model whose constraints are acceptable to cloud users, and whether that model will add to cloud revenues or just cannibalize the current cloud front-end base.
Those are the things I plan to explore with both cloud users and providers, and I’ll open it again when I think I have some useful answers.