The Right Tools for the Job

May 29, 2007 by Matt Ammerman

Are today’s SaaS enablement technologies robust enough to support business to business SaaS?  It’s a question I ask myself everytime I am introduced to a new ‘mashup engine’ or ‘online SaaS IDE’.  Granted, there are some very impressive products out there right now, Bungee Labs’ BungeeConnect and CogHead for example.  But initial impressions aside – are these whole product enablement environments robust enough to support extremely high levels of customization? Multi-tiered integration? Legacy integration? Complex computation and data types, and the myriad other requirements of the world’s most powerful business software? Even Salesforce’s proprietary Apex language born from Java seems a bit limiting in terms of programming expressiveness.  Or so I’ve heard.

CogHead made a statement in their early advertising that has stuck with me for awhile now – they said [paraphrasing] that “CogHead wasn’t designed for computational fluid dynamics calculations”, instead spotlighting ease of use for the business individual. The idea: an environment to quickly build business process applications, and it’s so easy that anybody in your business can do it.

The problem I have is not with the ingenuity or inventiveness of these types of environments. I think there is a ton of very cool, and applicable, things that can be done with them.  But I feel they alienate one crowd that, well, we owe pretty much everything to – software developers and engineers.  Those that have been schooled and trained in the complex sciences of computer programming and application engineering.  Believe it or not, but these folks are masters of an art – because there is a significant amount of expressiveness that goes into architecting an application, writing code, and optimizing it.  Furthermore, business to business SaaS includes applications and services that fundamentally require a powerful computational platform and languages expressive enough to harness the power of that platform.  I spoke with a vendor the other day who is looking for the right tools to develop an online service that provides genomic computation.  Yes, that’s right – genome sequencing for researchers, on demand.  

Some of the feedback I’ve read and heard from developers who’ve gotten their hands on languages such as Apex leads me to believe that developers’ hands are tied – even if they stretched the technology to its limits there’d be so much more they’d want to do with it that it’s almost not worth their time.  They’ve spent years honing skills in the .NET languages, in Java, PHP, Ruby, in name your favorite programming language – and now they’re being handed Javascript-based online IDEs and proprietary languages and told to deliver enterprise SaaS applications.  They’re being told by managers to port existing client\server code to an on-demand architecture using tools that simply don’t match up.

The tools exist, and developers have been using them for years.  They’re experts.  Perhaps SaaS enablers should focus on bringing the existing developer toolbet to the SaaS world, instead of enabling the rest of the business world around them with brand-spanking new tools that limit and eventually alienate developers.  Frankly, I think the novelty of so-easy-your-manager-could-do-it development tools will eventually wear off and the business world will turn back to developers looking for programmatic magic.  But, that’s a whole other post for another time.

The point is, handing an enterprise software developer some of these enablement tools and asking for a business-to-business SaaS application is like handing Mario Batali an EasyBake™ oven and asking for a six-course Italian dinner.  No matter the amount of genius and talent involved, there’s only so much you can do with a 100-watt lightbulb.

 

 

read more

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

May 21, 2007 by Sinclair Schuller

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

Will ‘Beta’ Fly in B2B SaaS?

May 9, 2007 by Matt Ammerman

“Beta”

The word somehow snuck its way into the plethora of Web 2.0 buzzwords. 

• GMail and Google Calendar!…beta. 
• Windows Live Alerts, Gallery, QnA, Soapbox, Office, and Mail!…beta. 
• Flickr!…gamma. (?) 

These services have hundreds of thousands (if not millions) of users and yet they still wear the beta badge.  Some have done so for nearly 2 years.  Clearly, there is an understanding and acceptance amongst the Web 2.0 user base that these services provide service ‘as is’ with little guarantee of anything.  We’ve heard stories of Gmail accounts being wiped, for instance.  And despite this, people are banking their entire business on Office 2.0 services.

I wonder to what extent this will fly in the enterprise SaaS world, where SLAs and guarantees make or break deals on a daily basis. From the consumer standpoint, trust is everything in SaaS.  From the provider standpoint, adoption is everything.  So the question is: Would consumers trust enterprise SaaS applications that wear the beta stamp?  Is it wise for providers to open up public betas of enterprise SaaS applications, or does the trust issue become prohibitive?  Obviously a major difference here is that the services listed above are ‘free’, while enterprise SaaS applications will presumably require subscription fees right out of the gate.  I’m just looking to get a handle on the psychological aspects of using beta software in the enterprise and how that translates to the SaaS model.

[poll=5]

read more

On User Density

May 8, 2007 by Sinclair Schuller

My last post discussed cost of revenue related to delivering a SaaS-offering to a subscriber base. Shortly after publishing it, I noticed that Gianpaolo Carraro posted this article, which toward the end discussed the relationship between cost and electricity/space within a datacenter. A while back, Gianpaolo described another metric: tenants per database and he described it as “density.” I think that really summarizes the electricity/real estate metric and is the best way to look at any SaaS metric. Drive cost of revenue (and even operational costs) down: maximize your density metrics. As a SaaS provider, you need to identify any “Users per X” or “Tenants per Y” and figure out ways to make that ratio bigger. Doing so will improve cost predictability, buffer against sudden cost change (distribution property), and most importantly it will build your economies. Changing these ratios isn’t easy, however. Most of the time, good density is achieved through advanced application architectures, good infrastructure configuration and carefull planning.

What are you doing to maximize your density metrics? Where are you having most problems? Let us know, we would love to know.

read more

Running a SaaS Business Costs Money?!?

May 6, 2007 by Sinclair Schuller

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):

 

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