According to ISVs, Salesforce’s Force.com is Not the Platform for SaaS

Mar 3, 2008 by Sinclair Schuller

I bumped into a brief but impactful article by Renee Boucher Ferguson titled “ISVs Snub Salesforce’s Force.com Platform“. The post basically summarized a situation that occurred after OpSource’s SaaS Summit. Following a panel discussion on SaaS platforms, ZDNet’s SaaS blogger Phil Wainewright conducted a brief poll of about 250 software vendors asking the following questions (paraphrased):

1. How many people were considering building a SaaS offering using their own development tools and having it hosted by a 3rd party?
2. How many people were looking at a software+services approach?
3. How many people were considering Salesforce’s Force.com (this is the fun one)?

About 40 or so ISVs responded yes to question 1. About 10 responded yes to question 2. A total of 2 hands were raised for number 3. Salesforce.com’s world changing, hard hitting, hyped up, super duper, all encompassing SaaS platform picked up 0.8% of the vote! Now, I hate to poke fun but that is quite the entertaining number.

(bigger)

In a conference targeting and attended by software companies looking to build SaaS applications, and after a panel discussion titled “Platform Choices Will Define On-Demand Opportunity”, Salesforce’s Force.com pulled in less than 1% of the vote. That’s as close to a unanimous “no” as you can get. It sounds like that a certain group of ISVs made it quite clear that they can’t excercise their right to opportunity via that particular platform choice. Despite how this post started, I don’t want this to turn into a rant against Salesforce and Force.com. The purpose of this post is to breakdown why something like Force.com doesn’t make sense for ISVs (which might account for the poor straw poll turnout).

If you’ve been a SaaSBlogs reader for a while, you’ll recall a post I wrote a while back addressing the problems with Salesforce’s approach to platforms via Force.com (or Apex, or whatever the marketing term of the day was). Now that Force.com is active and pursuing market share, many of the same things I mentioned hold true. What would cause only two hands to raise? That’s easy enough:

1. Limited capabilities - People love to think that software engineering has become complicated “just because.” The fact is, the problems we tackle when writing software are signicantly complex and grow more complex each day. The concept of something like Force.com started off as an extension platform for Salesforce.com, and not a general purpose platform. It does a good job at letting you be a spoke on Salesforce’s wheel but if you need to build a complex offering outsied that wheel, it won’t fit your need.
2. IP & Business Risk – Salesforce expects you to capture your company’s bread and butter – the software’s logic -  using their Apex language. Furthermore, Apex runs only within Salesforce.com. If you’re a serious ISV, the idea that your IP is tied to some random language and that if you don’t like how your app is being delivered you can’t leave is a scary proposition. The fact that you can’t take your toys out of Salesforce’s playground and go home is a ludicrous concept and difficult to swallow.
3. Force.com is About Marketing Not Product - To be fair, Force.com does provide a good distribution model since you have the ability to tap into Salesforce’s customer base, but that’s exactly why Force.com was built. Force.com is used as a mechanism to bolster Salesforce.com core offering’s value proposition. It’s primary purpose is not to give you the power to build powerful SaaS offerings. From the distribution model standpoint, it makes sense to write to Force.com if you’re writing plugins and extensions for their CRM product. For full blown SaaS offerings, look elsewhere.

When looking at those who develop software, I see ISVs and “the others” (for lack of a better category). ISVs have complex issues and software offerings with specific intricacies, existing IP that they want to port to a new delivery model and do not want to be a puppet to some other companies growth goals. “The others” look for successful products to piggy back on and are interested in tacking on value to an existing product. Both are valid and lucrative categories. When looking at Wainewright’s straw poll, I don’t think Salesforce’s marketing can attract people from the former category because it’s a square peg in a round hole situation. They had a great idea when it came to Force.com as an extension platform, but IMHO that idea went down south when they tried to cram it down ISVs throats rather than focusing on “the others”.

Do you think that the small poll was representative of the sentiments of ISVs in general or not?  In your opinion, why might ISVs shy away from deploying their business on Force.com?

 

read more

Should You Scale-proof SaaS Offerings Early?

Dec 7, 2007 by Sinclair Schuller

A SaaSBlogs reader recently sent me a link to an article by Dharmesh Shah over at OnStartups. In a nutshell, the post articulated that building a highly scalable architecture when creating a new application is premature and creates a large resource tax on a startup’s already limited resources. This led to a vibrant thread of comments with people arguing both sides, but one comment by Dharmesh really stood out (and surprisingly wasn’t even acknowledged in the remaining comments) was the following:

“One point I didn’t make in the article, but probably should have: When making tradeoffs regarding scalability, you are at some level incurring technology debt. Debt is not always a bad thing — it can often help you grow. The key is to make sure that the “interest rate” on the debt does not outweigh the benefit of the tradeoff. So, if making a scalability tradeoff will likely cause you to rewrite the entire system, it’s probably not worth it. But, if it’s simply a matter of “Pay X now or 1.2X later”, it might be better in some cases to just pay 1.2 X later”.”

This comment provides sound rationale to the “should I scale-proof my offering early” question. From the standpoint of an entrepreneur, don’t waste your resources if scaling is not your core business (because some products have that as a core function) or if the cost massively outweighs the benefit since your immediate goals should include getting your first (or fifth, or tenth) customer, not worrying about your one-thousandth. That said, if you can scale proof your application at a low cost and avoid incurring technology debt, it’s generally wise to do so. Looking at the boundary cases, it becomes obvious. I offer you two choices: you can engineer your application for a cost of x and not be able to handle reasonably large scale or spend 1.02x and be able to deal with really large scale if and when it comes. Generally, you’ll choose 1.02x since the cost is negligible and the risk mitigation is high (this is why we pay for health, auto or any other insurance). Conversely, if I told you that the cost was x but that engineering for scale would be 1.2x or worse (say even 2x) you would most likely opt out and rightly so. After all, imagine that auto insurance personally cost you the amount of a car each year, you’d likely do everything possible to avoid getting it (granted, there are intricacies such as personal injury, etc. but work with me here! These non-tangible intricacies even exist in software – it’s one thing if you’re app doesn’t scale and you can’t take on new customers, but what if it grinds operations to a halt long enough that you lose existing customers or reduces the stability of the application to zero)

The goal of SaaSGrid, aside from providing an execution runtime and business services for SaaS offerings, is to allow for scale-proofing a SaaS offering at a negligible cost, biasing the cost/benefit analysis highlighted by Dharmesh toward choosing to scale rather than opting to incur debt. We strive to push for that trivial case of making the choice “obvious.”

If you’ve participated in building a SaaS offering, did you deal with the scale question early or late and how did your experience turn out? Have you ever had a “windfall”, a rare but possible scenario where you don’t experience organic growth but rather experience a large fluctuation in customer traffic due to some event?

 

read more

The Not So Obvious Advantages of a SaaS Platform

Oct 29, 2007 by Sinclair Schuller

I’ve written about many of the obvious advantages of a SaaS platform before: harnessing a platform to reduce implementation time, cost of implementation and/or transition (for you ISVs with existing product lines), reduction in operational costs, and the list goes on. But what about not so obvious advantages? After some fruitful discussion with individuals at various organizations, I’ve identified some not so obvious advantages to building your next offering atop a SaaS platform (where the SaaS platform encapsulates a delivery, execution, and business services stack):

1. Cross Team Knowledge: In larger ISVs and corporations, multiple teams develop products in parallel and many times inadvertently duplicate efforts and functionality if good communications don’t exist between teams. If an ISV is pursuing multiple SaaS offerings across teams, standardizing on a SaaS platform (in-house or otherwise) creates common, transferable knowledge across teams. This creates baseline knowledge compatibility and teams can be useful to each other as they learn to exploit various parts of the platforms functionality.
2. Long Term Flexibility: Having a true SaaS platform as a foundation for a SaaS offerings creates a level of natural decoupling between the SaaS delivery stack and the products built on it. This allows for future products to be built atop the delivery platform since the platform tends toward abstraction rather than specialization. As a result, the flexibility of reusing the delivery mechanisms becomes a reality. In situations where the delivery stack and service are fused together, it becomes very difficult to use just the delivery platform. Far too often, the delivery stack was designed to fit the specific needs of the offering.
3. Independent Evolution: When infrastructure or non-strategic software is baked into a product, it takes an evolutionary back seat to strategic code that directly affects the value proposition of the offering. As a result, that part of the product never evolves, and new efficiencies end up being lost opportunities. Utilizing a decoupled platform allows for a powerful stack to evolve independently of the business functionality it hosts. This creates a powerful mutualism between the host and hosted software. What’s even more interesting is that using a third party rather than in-house platform can balloon this benefit since the platform evolves with wide and varied community input rather than in isolation.
4. Insulation via Isolation: Isolating delivery platform from product code creates an insulative (warning: insulative is a made up word) effect allowing for some degree of code portability as well as project creep safety. Having a baked in delivery stack results in a higher yield of bugs creeping up from the stack or down from the product, making quality control more difficult than necessary.

I’m sure that there are many more non-obvious benefits (I can think of a few more, but I think you get the point). Given these as well as the obvious benefits, it seems natural that over time the prevailing implementation choice would be to decouple the delivery stack from the strategic code, much like application and web servers did in the past. Do you agree or disagree? Has anyone experienced negative side-effects of baking the delivery and execution stack directly into the product? Feel free to comment!

 

read more

SaaS 101: The Drawbacks

Oct 16, 2007 by Abe Sultan

A while back I wrote an article called “SaaS 101: The Benefits” in which I discussed some of the benefits of the SaaS model for end users and software vendors alike. Of course, where there’s a yin there’s a yang, and so this article (a long time coming, we know) will explore the other side of the coin.

For the Customer & End User:

• No direct control of the data – One of the biggest hurdles to get over is the control of the data. Specifically, what happens when things go wrong? I’m sure every company trying to sell you a product will tell you that things can’t go wrong and that they will be there to support you for years to come. It is important that you ask the difficult questions: How safe is my data? Will I be able to download it? Will it be disposed of properly and safely? Can it be sold? Can anyone else host the application and my data? Will the application source be opened so that hosting can happen in house or by another provider? Stories of companies going belly up are not uncommon, and not only for SaaS companies but for traditional software companies as well. The only difference is that when a traditional software company goes under, the most you might lose is the years of support you were expecting from the vendor. When your SaaS provider goes under, deeper implications surrounding your vital business data have to be considered. 
• Internet connection required - I don’t know of many businesses that run without an internet connection these days. Nonetheless, it could affect your operations if you need to access an application and the internet connection is down.  A good set of companies are trying to solve this problem by allowing their applications to continue to work in a disconnected fashion for a period of time but at some point you will need to sync back up to the server. If this is a big concern for you make sure that your provider can address this need.
• Dependence on an outsider to run your business – In a big way, you are trusting an outsider to help you run your business, and if they are not keeping their end of the bargain it can really affect you. To keep it in perspective, these people are out there to stay in business and they do this for a living so arguably 95 out of 100 times they can do it a lot better than you could in house. This does not mean that you shouldn’t be aware of the implications so make sure you ask the tough questions.
• Security awareness – Another big hurdle is security. This concern is the umbrella that is home to the concerns above, as the common thread among them all is that they make you consider how “secure” you feel with SaaS. You are trusting your really valuable data to someone else. This can be a painful reality to accept but most security breaches occur because of disgruntled internal employees that end up selling or releasing the data when they are fired or when they quit, having your data managed and stored by an expert of the application is not a bad idea as long as they take it as seriously as you would. Again, it is in their best interest to do so but make sure you trust your provider the same way or more than you would trust your internal IT department and again, don’t forget to ask the tough questions!

For the Provider:

• Focus on customer satisfaction - This is one of those bad things that it’s good to have and makes great companies but we have to mention it anyways. SaaS providers need to focus on customer satisfaction month in and month out or they will lose their customers. They need to earn their customer’s business every month or they can simply leave. Contrary to on-premise deployments which are very costly and time consuming, if your customer is unhappy with the service he can up and leave at any time with very minimal cost. Some might argue that you can negotiate longer term contracts, make it hard to take their data and all other kind of shenanigans but if you ask me, it is bad practice and if you are not the best, then you better have one damn good reason why they should stick with you other than a binding contract.
• Harder development process – There are many different approaches to writing SaaS applications and they are outside the scope of this article but the bottom line is that there is a whole new set of things that you need to worry about when writing a SaaS application that you otherwise wouldn’t need if it were a traditional on-premise deployment. Things like tenant isolation, provisioning and scalability to mention a few could be a hard thing to tackle where you wouldn’t even have to think about if you were writing an on-premise application. Nowadays there are several companies working on “SaaS Platforms” including mine that make this a lot easier but none the less it’s something that you didn’t have to deal with before. For a great article on how to transition your company into SaaS read Sinclair’s article where he outlines a couple different strategies. Another thing that makes the development process harder is finding the right talent as the skill sets required are more advanced than for its on-premise counterpart but hey, who doesn’t enjoy a good challenge!?
• Compensation issues – One of the early problems for SaaS providers is how to maintain operations when there is only very little money coming in. Unlike traditional on-premise deployments where one deal could bring you $60,000 upfront and carry you for a couple of months while you close more deals, SaaS deals are MUCH smaller so initially it will be a lot harder to maintain operations unless you are properly funded so you can survive until enough money is coming in . Additionally the question of how you compensate your sales team can be a tough one to answer and can vary greatly depending on your offering. It might require you to offer higher base salaries and get creative with your commissions but without a doubt it can be one of the tougher operational questions you will encounter.  As an example let’s look at this scenario: Provider A sales an on-premise application for $2,500 a license. On a decent 20 seat deal they would bring $50,000 ($2,500 x 20) plus an additional $10,000 for support (usually 20%). Out of the $60,000 they would normally give anywhere between 1% to 4% commission to the sales rep leaving the company roughly $58,500 to run operations. In a comparable scenario where Provider B sales the same type of application as Provider A but as a SaaS application it will probably cost around $75 per seat so on the same 20 seat deal they would bring $1,500 a month taking over 3 years to reach the same $60,000 that the on-premise company received. You will need to come up with a good strategy on how to compensate your sales guys but at the same time have enough money to run the company.
• Success can be a problem – You’ve heard many times that being too successful is a great problem to have but in the case of SaaS it can literally bring you to your knees if you are not prepared. This goes back to my second point of SaaS being harder to develop. Things can grow out of control if the application is not architected properly and addresses scalability issues and your service can become unusable over time if it does not scale properly with the addition of new tenants. Make sure you don’t leave the hard decisions for later because you will run into a wall down the road.

After reading this article some of you are probably thinking “Damn, Why would anyone even think of getting into SaaS?!” But for the ones that are still not convinced check the benefits before making any decision. As with anything else you should always make a decision after you have considered all things good and bad.

What do you think? Does it make sense to jump into SaaS from end user and provider perspectives? Do the benefits outweigh the drawbacks? Or is it the other way around?

[poll=7]

We’d love to hear your opinions, so leave your comments!

 

read more

Level 3 Platforms & Creativity

Sep 18, 2007 by Sinclair Schuller

Marc Andreessen posted an excellent article breaking down Internet platforms into three “levels”. If you only have time for one article you would be better off to read his than mine but to summarize, the levels are described as:

• Level 1: API driven, app lives outside of the “platform” (Think Flickr)
• Level 2: Plugging an extension via an API into an existing app (Think Facebook)
• Level 3: A runtime where code lives entirely on the platform and the platforms purpose is to host applications (Think SaaSGrid – disclosure: SaaSGrid is the platform my company Apprenda will be opening to beta soon.)

The most important takeaway from Andreessen’s post is his statement that:

“I [Andreessen] believe that in the long run, all credible large-scale Internet companies will provide Level 3 platforms. Those that don’t won’t be competitive with those that do, because those that do will give their users the ability to so easily customize and program as to unleash supernovas of creativity.”

Reading that quote summarizes our mission with SaaSGrid and my personal perspective on the SaaS platform concept in general. If as a software engineer or development studio one can focus on what’s important and let Level 3 platforms do the grunt work, the ability to work “outside the box” becomes very real, and the quality and value of applications skyrocket. Once a Level 3 platform becomes established, it can very quickly continue to introduce value to the applications deployed on it.

 

read more