The Death of an ISV: How NOT to Succeed in your Move to SaaS

Jul 27, 2011 by

It wasn’t curiosity. It was thinking that the “good old” ASP model would cut it. It was thinking that little by little, they’d get away from labor intensive provisioning, manual billing, and some day refactor the Rube Goldberg contraption that made their “hosted” model work. Sound familiar?

Software as a Service has quickly become the preferred method of application delivery and consumption. Why is it that while many ISVs claim to provide some flavor of SaaS today, few are doing it with the same cost of delivery profile and operational agility as SaaS leaders like Salesforce.com, or Taleo?

Join Apprenda and Savvis on August 9th at 1:30PM EST for a webinar covering the most dangerous pitfalls that ISVs fall into time and time again. You’ll learn:

- The unprofitable truth about the ASP model
- Why multi-tenant infrastructure isn’t enough
- The real-world economics of SaaS leaders and laggards
- How to avoid building dozens of custom SaaS operations systems
- Key business and technical pitfalls when making an infrastructure choice

You’ll come away with everything you need to either “save the ship”, or leap frog your competitors with a SaaS strategy that rivals the best of the best.

Date: Tuesday, August 9, 2011
Time: 1:30 PM – 2:30 PM EDT

Register Here>

We hope you’ll join us!

read more

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

Mar 3, 2008 by

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.

saas_impl.png
(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

Smoke & Mirrors Alert: What is Salesforce Trying to Say?

May 21, 2007 by

Although most people don’t realize it, plenty of advertising and announcement techniques use “sleight of hand” style approaches to exploit your first glance and focus your attention on the content of the ad and an intended message rather than seeing the truth. This technique is common among propagandists and corporations alike. Let’s look at some examples:

  • Undoubtedly, you have seen the phrase “Made with All Natural Ingredients” on food packaging. Many consumers see that and think – Wow, it’s an all natural product! Well, no. The phrase is simply stating that at least one ingredient in the food product is natural – all the rest can be artificial, and the label would not be telling a lie. This statement creates a large gap between understanding and meaning, giving the advertiser plenty of “wiggle room.”
  • “No soap cleans better” or “No detergent kills more bacteria than X” is another one of my favorites. To a casual reader, this is generally understood as a claim that a specific cleaning product is better than the rest – it defines a less than clause. The true meaning, however, allows for the case that all other detergents clean equally as well as the subject product, meaning that it in fact cleans no better. This creates a situation where “No detergent kills more bacteria than X” and “All detergents kill the same amount of bacteria”
    can in fact be synonymous.

Generally, using these tactics help out a ton when trying to position a product or service. So what does this have to do with Salesforce.com? Well, they’ve become quite keen on using this approach (aka smoke & mirrors). A couple of weeks ago, Phil Wainewright asked the question “How is AppExchange really doing?” where he highlights that they’ve played “fast-and-loose” (what a great phrase!) with their numbers in touting the “popularity” of Apex & the AppExchange. Salesforce.com has conveniently made sure that all of its CRM customers are considered Apex customers. According to this page, Apex as a platform is used by 32,300 customers. That makes it seem like the Apex platform has been privy to massive adoption. Just like all natural ingredients or killer soap, however, their assertions lack the necessary clarification. Salesforce.com, the CRM product, is counted in those figures. So as Mr. Wainewright asked, how well is AppExchange really doing? In October of last year, Josh Greenbaum called analyzing AppExchange a “guessing game” and I wrote an article on some of the applications found in the AppExchange.

Well, looks like Salesforce.com is at it again.

A press release issued today announced the AppExchange Venture Network and states that “More than $225 million has been invested in two dozen companies on the AppExchange.” At first glance, you think – Wow, venture money is really flowing to software companies building apps on the AppExchange. What did we learn about first glances? You guessed it – this has some artificial ingredients! The statement is intended to give off the message that money is pouring into the AppExchange. This is nothing but marketing at its best. $225 million most likely has been invested – but it went to building the companies and their primary SaaS offerings, and not their Salesforce.com integration do-hickeys. Salesforce.com is using the companies and their funding as a proxy marketing message, almost like mathematical syllogism: since A>B>C then A>C. Better yet, let’s look at the possible roots of the message: Since $225 million has been invested in two dozen companies, and those companies each built integrations between Salesforce.com and their application and published it on AppExchange, then “…$225 million has been invested in two dozen companies on the AppExchange.”! I can see how building these messages can be addicting! Now, spin that into the general purpose platform message of Apex, and you have a platform with hundreds of ‘applications’ – right.

What do you think? Do you see these marketing tactics used frequently? Have any good examples that you’d care to share?

read more

Running a SaaS Business Costs Money?!?

May 6, 2007 by

Being in the SaaS platform space, one of my passions (yes, really) is to breakdown the SaaS provider model and figure out where costs are. The one area that is most intriguing is cost of revenue (CoR) - that is, costs directly associated with delivering the service to end users. This cost generally includes, but is not limited to:

  1. Bandwidth
  2. Hardware(Amortized) & Hardware Related Expenses
  3. Operations Staff (if applicable)
  4. Storage
  5. Backup & Recovery
  6. Licenses
  7. Co-location (real estate, electricity, cooling, etc.)
  8. Product Support

Basically, any cost that is proportional to and incremented with a rise in your subscriber base, is relatively predictable, and is directly responsible for service delivery is part of cost of revenue. Now, I’ve read blog posts and spoken with people that have made comments like “SaaS shouldn’t be very expensive, after all Web 2.0 is about starting companies in a capital efficient manner” or “Digg.com scaled to tens of thousands of users with only a couple of servers.” While I agree with those observations, they don’t really play into true SaaS. SaaS is not about applications with shoddy reliability, or about applications that have simple, repeated read/write transactions. SaaS is about stable, reliable, customizable, and robust business applications. As a provider to other businesses, you have an ingrained duty to provide fanatical (borrowed from Rackspace) service and uptime. These properties requirements do one thing and one thing well: they increase the cost of service. To drive costs down, you need to become operationally efficient, make wise architectural choices at both the software and hardware level, automate as much as possible, and meticulously maintain metrics. No programming language/framework combo (yes, not even the panacea of the day, Ruby on Rails) can save you from poor architecture, inability to automate, and nack for getting operations wrong.

So, as a provider, what does it cost to run a service? To answer that, we have two primary sources: (1) the financials of publicly traded SaaS companies and (2) discussions with some private SaaS companies. I’ll start with public companies. For public company’s I took a look at members of the SEG SaaS Index, including Taleo, Salesforce.com, RightNow, Workstream (not on index), and DealerTrack. I’ve extracted what they consider to be “Cost of Revenue” and generally have a description that goes like so:

Cost of application revenue primarily consists of expenses related to hosting our application and providing support, including employee related costs for network related staff, the depreciation expense associated with computer equipment and the cost of extra data center capacity.

Here is the breakdown for 2006 alone, accounting only for revenue and cost generated by subscriptions ($ in thousands):

Cost Of Revenue

 

As a percentage of revenue, there is a large amount of variation. TRAK is the only oddball because they factor in “revenue share”, which is some sort of commission paid to 3rd parties, thereby driving CoR up. The other data samples adhere quite closely to the aforementioned description. Interestingly, this provides some rudimentary evidence for economies of scale (factoring out TRAK): Salesforce.com has the highest revenue and best CoR percentage, with WorkStream having the worst and the other two falling in order between them.

Having had conversations with smaller, private SaaS providers, the picture is even bleaker. Many times, starting off requires a provider to overpurchase to provide availability and over-capacity, yielding CoR that is higher than revenues. Overtime, the companies I have spoken to begin reducing CoR as economies kick in, but even those in the $10 million – $30 million range are still in the 20% - 25% band for CoR. Delivering a SaaS application is not inexpensive.
This highlights something very important: the best in the industry manages 14% with others nearing 30%. Take that into account when analyzing your costs. Yes, costs have and will go down for things like hardware, bandwidth, etc., but remember that will means in the future, and that there is still uncertainty. Many SaaS providers are looking at utilizing service solutions such as billing or an entire delivery platform (disclosure, self promotion). The data above should give you a good baseline to work from when deciding if something is expensive or whether your projections are in-synch. If you’re a SaaS provider, is your CoR experience relatively similar? Do you factor in other things, or leave things out that I’ve included? I’m anxious to hear your thoughts.

read more

SaaS 101: The Benefits

May 2, 2007 by

Viva la SaaS!In Matt’s previous post, he made mention that the true sign of SaaS’s arrival is that it has garnered the sincere interest, and better yet dollars, of the investment community.  More people in a greater array of business roles are giving SaaS the ol’ thumbs up.

We’ve established that the pursuit of SaaS is on the minds of *almost* everyone, but what is it about SaaS that gives us all the warm and fuzzies?  For the most part, SaaS is still a nascent industry.  It wasn’t long ago the purveyors of SaaS applications or enablement technologies were referred to as the tech industry’s “lunatic fringe”.  Strangely, the benefits of SaaS have emerged and shown a bright light on the future of all those involved in delivering software functionality to businesses.  So, what are these benefits? This may read like a SaaS 101 laundry list… but to see where SaaS is going, it might be best to take another look at the fundamentals.

For the Consumer:

  • No client/server software installation or maintenance – that’s right, no more 800-page planning and implementation guides.
  • Shorter deployment time – potentially minutes as opposed to a phased implementation that could take months (see item #1)
  • Global availability – sure the technology exists to make on-premise software available outside of the premises, but we’re talking about functionality that is available from anywhere on the internet natively.
  • Service Level Agreement (SLA) adherence – reported bugs can be fixed minus any rollout overhead.  Sure the provider actually has to fix the issue, but assuming they’ve deployed a moderately efficient SaaS application the rollout of a patch or fix should happen in the blink of an eye.
  • Constant, Smaller, Upgrades – when you use a SaaS application, it is in the best interest of the provider to keep you happy and they can do so by constantly improving the application experience.  With SaaS this can come in the form of consistent miniscule changes that add up over time instead of monster patch and upgrades that cost you time and money to implement.
  • Ease Your Internal IT Pains - This is a big one. Most of the last several points here highlight that SaaS offloads a great deal of IT pains incurred by software consumers in the traditional client/server model.  This leaves IT personnel to focus on improving the day-to-day technical operations of your company instead of being called upon to troubleshoot 3rd party software or maintain aging infrastructure.  Which leads to…
  • Redistribute IT Budget – by outsourcing software functionality to a provider, the enterprise realizes a cost savings in infrastructure requirements and IT personnel knowledge requirements.  This allows the enterprise to focus on core competencies.  It also means that the cost savings from using SaaS applications can be flat out saved, or reallocated to boost productivity through other services.

For the Provider:

  • Aggregate operating environment - as a provider, you own your domain.  No longer are you sending technicians to fix or customize your software because it doesn’t fit into a customer’s highly-specialized (or horribly outdated) infrastructure.  You have complete control to optimize an infrastructure to your SaaS application’s specific requirements.  This is synergy at its best, and leads to financial savings as well as less headaches.
  • Predictable Revenue Stream - the subscription model associated with SaaS means that your customers will pay you on a recurring schedule.  If you make this cycle flexible enough, you can get a real handle on forecasting revenues.  The payment may be tied to your product (think cell phone plans) where everybody pays according to the same term, or tied to your individual subscribers where some may pay monthly, some yearly, and some quarterly.  In my opinion, the more flexible you are with this piece of the offering the better.  Either way, because of the scheduled nature of cash inflow, revenue modeling becomes more reliable.
  • Predictable Growth - Same as above, but here we’re talking about sheer volume of subscribership.  The fact that users hit your site to access the application means that with the right tools you can monitor their usage pretty closely – something that’s not so easy with all your customers running the application on premise.
  • Focus On Smaller Upgrades Instead of Monster Patch Rollouts – and while you’re at it, don’t worry about rollout logistics across all of your customer sites either.  Your development teams can focus on fixing core application functionality, tackling bugs and enhancing features in smaller incremental rollouts because it’s just easier to do so.
  • Sales Becomes Customer Relationship Management – When you are selling a subscribable service, the game of gaining subscribership becomes one of balancing user retention vs. attrition more than a game of landing the ‘big deals’.  Sure, it’s important to have a team out there pounding the pavement to sell your application – i.e. getting subscribers in the door - but the real thrust of the new sales and marketing in SaaS is customer relationship management.  The equation becomes quite simple – keep retention rates higher than attrition rates and focus on bringing in new customers.

Adoption of the model has been growing at well over 20% year over year, Nick Carr says (paraphrased) that SaaS adoption is set to explode and reports that McKinsey & Co. will release a survey showing that 61 percent of CIOs at North American companies with sales over $1 billion are already planning to adopt one or more SaaS application.  Additionally he says that Deutsche Bank projected that the SaaS market will account for half of the application software spend by 2013, Gartner predicts that SaaS will triple in size by 2011 from 2006, Jeff Kaplan thinks SaaS adoption is underrated and the success of companies like SalesForce.com should be enough to convince even the most skeptical, but if all of this is still not enough and you are having trouble convincing your customers, your boss or yourself into adopting SaaS, here is a list of benefits to consider.

What do you think? Have you experienced other benefits already? On the contrary, have you experienced major drawbacks? We would love to know what’s holding you back or what has pushed you forward!

read more