It Costs More to Be a SaaS Company. How Platforms May Fix That.

Jan 25, 2007 by

Yesterday, Will Price of Hummer Winblad wrote a terrific quantitative analysis comparing the upfront funding needs of SaaS vendors, or application providers, with the funding needs of traditional software firms. In case there was any doubt, his data shows that funding a SaaS endeavor requires substantially more money – on the order of 3.65 times more capital, in fact. His article is titled “The Economics of SaaS: We Need a Platform.”

Mr. Price’s funding breakdown consists of data for publicly traded software companies in both the enterprise client/server space, and those that have reached IPO with primary SaaS offerings. His numbers add substantive clout to the prevailing, though often questioned, thought that starting a SaaS company or moving existing business to the SaaS model costs more than the traditional client/server model. Mr. Price deduces that the way to reduce SaaS development costs is to speed up development time – to get to revenue quicker. But how? Well, it’s no surprise that Mr. Price provides the platform as the answer. Solving the time to market and infrastructure overhead hurdles for SaaS vendors is what us platform developers refer to as ‘The Problem’.

read more

Maintaining Dual Products with Salesforce.com’s Apex: Does it Make Sense?

Jan 22, 2007 by

I recently read a comment by Marc Benioff that baffled me. Dan Farber recently interviewed him and summarized the interview in his latest post Salesforce.com’s platform ambitions. In the interview, Farber asks Benioff whether a company like SuccessFactors should write natively to the Apex platform instead of just integrating with Salesforce.com through the sForce API. Here is the excerpt from Farber’s post:

“I [Farber] asked him [Benioff] whether a company like SuccessFactors, which has an HR on demand application with more than 2 million subscribers, should write to the Apex platform, rather than just integrate with the salesforce CRM application through Web services. ‘I think it would be wise to natively support our platform and have a version on their’s. There is no reason not to do both,’ he said. ‘I am sure their competitors will if they don’t…’”

Say it ain’t so! Hopefully one you (the readers) can help clarify this for me, as my nimble mind seems to be crippled by the weight of Benioff’s reply. What I got out of it is that Benioff recommends you, the software engineer or ISV, maintain two equivalent products as two implementations: one of your own likings and one using the ultra cool, ultra fantastic (sarcasm) proprietary and closed Apex language and stack. That is, maintain two code bases, market two products (I guess one to Salesforce.com customers and one to everyone else??), patch two different products when you find bugs, etc. Oh, and by the way, if you don’t your competition will; the advantage of spreading themselves thin will undoubtedly endow your competitor with the ability to crush you in share of market numbers. Ok, I must admit, that’s simply my take on that excerpt (and don’t forget my disclosure, I founded a SaaS platform company of my own) so I’m asking anyone reading this to weigh in: what do you think Benioff was trying to say? Did I understand it correctly?

read more

SaaS Ecosystems: Are They Valuable and To Whom?

Jan 11, 2007 by

At first glance, the concept of a SaaS ecosystem seems to provide value only for the end user, giving SaaS customers a map benevolently drawn by the divine cartographers of their SaaS/ecosystem providers to navigate the ever growing jungle of offerings and value propositions. But as the age old saying “Never judge a book by its cover” implies, take a look below the surface.

First, do ecosystems provide value to the end user? Absolutely. SaaS ecosystems, by nature, create a synergistic effect and positive sum game for the end user. The concept of the ecosystem allows for the exploitation of its participants to the benefit of the end user. For example, as an end user buying into a SaaS service with a budding ecosystem, I can take advantage of the tight integrations I’ll likely find between the ecosystem’s members, making for a smoother ride. Conversely, if I were to buy into a SaaS service A and a disparate SaaS service B, odds are that I won’t be able to exploit a relationship or integration between them as easily as I would in finding a reasonable B substitute within A’s ecosystem. Extrapolate this to all of your software purchases, and you can see that synergy unfold or disappear, depending on which poison you chose. There is definitely value in buying into an ecosystem, but is the ecosystem really a result of provider benevolence? Probably not.

Before I get into why providers extract value from ecosystems as well, let’s think about what SaaS has done to the end user’s ability to find substitute providers for a given service type. Prior to the advent of SaaS, an end user would purchase and implement an on-premise solution for an exorbitant amount of money, time, and effort. This placed the customer in a precarious strategic “stuck between a rock and a hard place” situation: if the software product proved to be worth less than what its cost was, finding a substitute was generally unreasonable since they would have to re-incur all of those exorbitant costs for the replacement. In essence, the on-premise model greatly reduced a customer’s replacement mobility which would generally correlate to a reduced customer flight risk for the vendor. Think of replacement mobility as the product of having substitute options coupled with your ability to leave your current software choice and flight risk as the risk of a SaaS provider losing a customer due to the customers replacement mobility. A reduced flight risk meant that even though the customer disliked the product, they would probably continue to invest in it by purchasing small upgrades, support, and customizations from the vendor. Obviously, the vendor liked this. SaaS, however, turned this model on its head. Assuming a customer can access their data, the cost of switching from one vendor to a substitute is much less pronounced than the on-premise model. This difference created a value gain (in green) for the customer and a value loss (in red) for the vendor when contrasting with the on-premise model.

(bigger)

SaaS vendors are aware of this, forcing them to place a large amount of focus on delivering quality functionality and service to reduce attrition rather than rely on the artificial retention dam created by the high cost of implementing on-premise. Although customers view this as fair, vendors (particularly those who used to sell on-premise) view this as sour grapes. The ecosystem, however, helps reallocate some of the customers large value gain back to the vendor. When a vendor deploys an ecosystem and populates it with value-added partners, it is providing the customer more value while also making it more difficult for the customer to leave in events of teetering dissatisfaction. A customer acting as an ecosystem consumer now has to ask “Can I find a substitute for the SaaS service and the value I’m deriving from the ecosystem.” Being a more difficult replacement proposition might force the customer to overlook some levels of dissatisfaction they may not have overlooked if they were not consuming from the ecosystem, thereby placing less onus on the vendor.

(bigger)

Does the ecosystem provide value to the vendor? Absolutely. The ecosystem can generally be considered a win-win, as long as the customer is aware that it will affect their replacement mobility. So how do you feel about ecosystems? Do you think they’re all hype, or actually add value to a SaaS offering or platform? If you’re a provider, do you see value in reducing attrition rates through a tactic like this?

 

read more

Apprenda at SaaSCon ‘07

Jan 10, 2007 by

Apprenda, developer of an upcoming general purpose SaaS platform for ISVs, is a sponsor of the SaasCon Conference which will take place April 17th and 18th in Santa Clara, CA.

Apprenda will also be on the exhibition floor at booth 416.

 

 

read more

The Evolution of SaaS

Jan 8, 2007 by

Regardless of whether one believes that Darwinian evolution is how the species of this planet came to be, most will agree that the premise and underlying structure of evolution is both powerful and to some degree measurable in the real world. One of the most important things to ask IS “Why study history and why attempt to understand the underpinnings of our origins?” The answer, in my opinion, is simple: we study history to mitigate risk in the present and future, and build on a foundation of measurable results. That said, understanding how SaaS came to be, and where it’s heading with the powerful concepts of the SaaS Platform and ecosystem. This complements one of my earlier posts regarding the categorization of SaaS, and I’m definitely looking for input as I view the unfolding of these definitions a communal effort.

I find that diagrams do a much better job at explaining concepts rather than multiple paragraphs of banter. As a result, I’ve put together a brief overview of how I see the evolution of SaaS unfolding. The evolutionary variable (measured over time) is how SaaS was/is implemented:

(bigger)

The timeline focuses how SaaS (On Demand) implementations have changed. Generally, implementation can be hidden from a user, but that’s not always the case. For example, a “streamed” application like Office 2007, while it would fall under the category On Demand, is far different than say Zoho’s web office, both from the implementation standpoint and the viewpoint of the end user. Looking at the timeline, however, one underlying theme is present: overtime, implementations converge to abstraction. We see this all the time in the IT industry, whether it’s the operating system abstracting the hardware layer (HAL), development languages such as C# and Java abstracting away some of the more difficult concepts such as memory management, our industry noticeably thrives on simplifying through abstraction. This is how we become more efficient, less vulnerable; abstraction helps us become a well-oiled machine and helps the end user see more and more value. With this abstraction also comes the ability to harness it as a common ground through concepts such as valuable SaaS ecosystems. Prior to platform and platform-esque implementations, the concept of the ecosystem would have been overly difficult to introduce and implement correctly. The evolution of SaaS is continually refining the various SaaS species to be more in-tune with the long term, ensuring that it’s here to survive the long haul (short of a catastrophic asteroid landing, of course).

SaaS is continually pushing towards a day where both use and development of SaaS applications is easier. Nonetheless, many of the early SaaS successes (Salesforce.com, WebEx, RightNow, etc.) were the precursors to this abstraction, which is something that the industry should value since they laid the groundwork for moving forward and turning SaaS into a viable delivery mechanism. Now, these same industry leaders are trying to move into a more abstract space with their own product-centric platform introductions. While they may succeed, history has shown us that it’s not the oldest species that survives, but the smartest, and these companies are going to face a slew of new SaaS platform players. These SaaS players are looking to enable the next-generation of applications for the enterprise, and hope to carry the genetics of SaaS but leave those early species behind with the dinosaurs.

read more