Salesforce.com’s Heroku Acquisition: A Clear Stake in the Ground

Dec 25, 2010 by Sinclair Schuller

Salesforce.com, over the past few years, has been reinventing itself as a platform company. IMHO, this is an extremely difficult thing to do for a company who’s cash flow is defined by the CRM market, an acronym that Salesforce.com adopted as a stock ticker. When Salesforce.com first announced Apex, it’s new fangled programming language and pseudo-stack, I took a highly critical stance because it was a clear attempt by a marketing and business team to tackle problems that only technologists can properly understand: building runtimes and frameworks that could provide a foundation for future software in the Cloud. My gripe was that Salesforce chose to create a new language that wasn’t rooted in a development paradigm shift where changes in a programmers ability to express solutions are the motivator, and instead decided to base the language development on seemingly more selfish interests and coupled the languages runtime to their operating and hosting environment. Essentially, they created vertically integrated lock-in, which is terrible for customers and the lack of purer motivations on the language development side produced a sub-par development stack best suited for small add ons.

Now we’re in 2010, and the story is starting to change, and seemingly for the better. At Dreamforce this year, Salesforce.com announced the acquisition of Heroku, the well known Ruby PaaS. Not too long ago, Salesforce.com and VMWare announced VMForce, bringing Java into the Salesforce.com cloud. Salesforce.com’s  evolution seems to be taking it down a path of stack agnosticism. This could be due to good strategic decisions making, or out of an attempt to correct a failed path with Force.com/Apex. Whatever the case maybe, its clear that Salesforce.com is embracing other stacks, and no longer focusing on creating a new $1 billion business by brute force.

It will be interesting to see where Salesforce.com goes with this. Will they make Java officially part of their Cloud by folding up a partnership with VMWare and instead make a Java Cloud their own competency? Might they go after Microsoft’s base by building or acquiring a value proposition that targets .NET developers and attempts to attract that group (who own 40% or so of the development market share) away from Azure? Who knows how far they’ll go, but one thing is clear: the Heroku acquisition clearly signaled that they want to do something different, and that something includes languages and runtime’s well outside of Apex. I really am glad that they’re adding true value and no longer beating the Force.com drum exclusively.

How do you feel about Salesforce.com’s Heroku acquisition? Any predictions on the success or failure?

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3600+ members and is growing every day; make sure you’ re not missing out and join today!

read more

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

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

Vendor Perception of the SaaS Platform Landscape

Mar 28, 2007 by Matt Ammerman

We’ve written quite a bit here about Salesforce’s Apex… and, admittedly, we’ve taken a somewhat critical stance on it.  Questions of identity crisis and ambiguity have boiled down to “Is it a SaaS platform, or a CRM platform? Is there a difference, and does it really matter what they call it as long as it is what I need?”  Frankly, I don’t think Salesforce has done a clear enough job defining what it is, and what it isn’t.  If I simply relied on their homepage description of Apex:  “A ground-breaking platform for customizing and integrating CRM, as well as developing and deploying brand-new applications, ” I might chalk this up to semantics – but understanding how the Apex technology stack works, one gets a better understanding of how closely tied it is to the Salesforce.com application codebase.  This satisfies part one of their description – but the growth of Apex as a SaaS platform vs. CRM platform will rely heavily on how far it can deviate from the Salesforce.com application.  This, of course, remains to be seen.

As SaaSBlogs and pretty much the rest of the SaaS blogging community (SaaSWeek, Phil Wainewright, Jeff Kaplan, among many others) took note of last week, Opsource announced the Optimal OnDemand 2.0 SaaS Platform.  Opsource really caught our attention with this one because of the way Optimal OnDemand 2.0 seems to quell some of our contentions with Salesforce’s Apex platform concept and other ‘niche’ platform concepts to date.  Opsource’s core competencies have been in the hosting infrastructure and provisioning realm, but with OOD2.0 they are introducing value adds further up the stack that fulfill SaaS hosting requirements (read: vendor pain points).  It’s a tremendous boon to the notion that to build robust SaaS applications, vendors will rely on platforms that provide general purpose technological and business value rather than platforms with a bent towards a particular vertical market or spawned from an application codebase. 

The introduction of OOD2.0 is big not only because of its impact, or dent, in relative size to the landscape of SaaS platform offerings, but because of how much it contributes to the growth of the landscape in terms of overall value.  Given that the landscape is, at least for now, shaped by a veritable combination of niche platforms and newer large scope general purpose platforms such as Opsource’s OOD2.0 and Apprenda’s platform offering - which type of platform has more perceived value to the ISV?  For instance, if I aim to build a project management application, should I utilize a proprietary hosting platform that offers a toolset strategically designed for project management applications (perhaps even built from one) but is limiting in terms of scope?  Or do I want to host my application on a general purpose platform that provides multiple tenets of SaaS as a base but does not intend to provide toolsets for strategy-related aspects of the application?

A better question at this stage is whether not this type of question is perceived as one of semantics or of real technical merit.  If you’re currently building a SaaS application, or simply doing research for a future project, I’m interested in learning where your search has taken you across the unfolding landscape, and where you’ve seen the most value in terms of SaaS platform offerings.

 

read more