SaaS Blogs

It’s been a few months now since Salesforce.com introduced Apex to the world, and we’ve all had ample time to digest the concept, analyze it, debate about it, and just generally figure out our own positions on the proposition.  One thing’s for sure, the announcement of Apex brought the total level of industry ’saas platform’ buzz somewhere into the realm of, oh, stratospheric.  Salesforce.com, of course, should be commended for this.  But now here we are roughly five months later and the landscape for SaaS in the enterprise software market, regardless of Apex, has grown and changed drastically.  Platform players have emerged, some having SaaS platform offerings in development long before the Apex announcement.  Some pure play SaaS application vendors are backpedaling to attack the platform need.  Some platforms formed through partnerships between partial solution providers.  Although we may use the term ‘platform’ for them all, there are decidedly different approaches to the concept, even this early in the game.  So now that the field has widened we can frame Apex against a broader notion of SaaS platforms, their requirements, and the different approaches being taken to provide SaaS enablement.  It is time to re-examine our initial response to Apex.  I wonder, is Apex really what SaaS vendors need?  In fact, I dare ask: is it really a platform?

As has been the case before, Salesforce’s own marketing messages have kindled these kinds of questions in my mind.  The kind of questions that make me furrow my brow and think “Just what do they really mean by that?”  Take, for example:

1. George Hu, Salesforce.com’s chief marketing officer said during a keynote speech to an audience of developers: “Go out and create the next Salesforce.com” 
2. A press release dated Jan 16 of this year reads “With Apex, Anyone Can Create the Next Salesforce.com ”
3. And you know I’m not going to leave this one out: Speaking to an audience of customers, CEO Marc Benioff said “We want you to be the next Salesforce.com” 

Sure it seems like a kind-hearted message with success written all over it, and it is undeniably unified in its presentation.  But now couple that mantra with the technological implementation that is Apex and here is where the meat of my questions arise.  According to their own Apex landing page, Salesforce.com wants you to create the next Salesforce.com using the ”same tools that salesforce.com’s own development team uses to build” [salesforce.com].  Besides being a lot of Salesforce.com’s in one sentence, this seems like a cleverly veiled way of saying “we’ll let you build the next Salesforce.com, but no better.  And we’ll keep you from doing this by giving you only the tools that we give our own application developers (or gave them months ago)… who you may ultimately be competing with.”  Remember, a good deal of Salesforce.com’s AppExchange apps are indeed of their own making.  See, this way Salesforce.com’s own developers define a ceiling… a guarded gate through which the ISVs they are ‘enabling’ cannot pass through.  You see, you can’t really create the next Salesforce.com; you may be able to create what Salesforce.com is today.  Tomorrow Salesforce.com will have progressed, and then you can try to be that.  Sound fun?  Sound endless?  By bringing in developers through Apex, Salesforce.com is swallowing competition in an enterprise application market that it is certainly not abandoning.  Is Apex simply a vehicle for making sure that Salesforce.com stays ahead of the game?  After all, if you outgrow or otherwise find little need for the tools provided to you by Apex, you pretty much have to dismantle your application and start over on a different technology stack - putting you far far behind.  Sounds kind of Borg-ish to me.  Come to think of it… didn’t we talk about the risks of this thing called lock-in before?  In the case of Apex we might be talking about lock-in through assimilation!  Heck, you even have to learn the Apex language.  I rest my case.

In all fairness, an answer to this question may require a solid grasp of the definition of ‘platform’, and in the context of the SaaS world this definition is constantly being tugged at and remolded.  However, here’s something to start with:  I propose that a true SaaS platform, one that will in fact revolutionize the industry from the perspective of the ISV and end user alike, is not a body of technological implementation that binds and assimilates and attempts to lead by example (Ahem. “We want you to be us.”), but one that can better be likened to the traditional concept of the platform that is used for elevation - not of the platform itself, but of those that stand upon it.  Yes, I am saying that a SaaS platform must get out of the way of the applications, and likewise the ISV business models, it enables.  ISVs will find true enablement through a platform that serves only one purpose, and does it well - to make the development and delivery of robust enterprise SaaS applications as easy as writing software and delivering it on premise.  To elevate, or enable, without demanding explicit recognition from the application or those that use it meets the true definition of a platform. A platform is a very humble, simple, and oft overlooked thing - yet a well-engineered platform silently keeps entities aloft that are many times its size.

And so I turn it over to you:

Is Apex really a platform?

 

*** UPDATE 2/7/07 9:56am ***

Marketing Consultant Joe Bentzel wrote a similarly-themed article a couple of weeks ago.  This is terrific further reading: Salesforce.com APEX: Platform or ‘Platformula’?