Comments on: Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/ Understanding the Software as a Service Revolution Fri, 21 Nov 2008 13:43:56 +0000 http://wordpress.org/?v=2.5 By: SaaS Blogs - » According to ISVs, Salesforce’s Force.com is Not the Platform for SaaS http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-37203 SaaS Blogs - » According to ISVs, Salesforce’s Force.com is Not the Platform for SaaS Mon, 03 Mar 2008 10:59:27 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-37203 [...] 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: [...] […] 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: […]

]]> By: SaaS Blogs - » Is Salesforce.com’s Apex a Platform? http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-999 SaaS Blogs - » Is Salesforce.com’s Apex a Platform? Tue, 06 Feb 2007 06:52:38 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-999 [...] 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 [their] own apps.”  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… who you will ultimately be competing with.”  See, this way Salesforce.com’s own developers define a ceiling… a gaurded gate through which the ISVs they are ‘enabling’ cannot surpass them.  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 space that it is certainly not giving up.  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 Salesforce, you’d 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. [...] […] 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 [their] own apps.”  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… who you will ultimately be competing with.”  See, this way Salesforce.com’s own developers define a ceiling… a gaurded gate through which the ISVs they are ‘enabling’ cannot surpass them.  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 space that it is certainly not giving up.  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 Salesforce, you’d 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. […]

]]> By: Sinclair Schuller http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-764 Sinclair Schuller Tue, 23 Jan 2007 12:00:43 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-764 Hi Arun, Thanks for commenting. Currently, the only viable alternative is to piece together custom code with various SaaS components available by providers. The problem is, this still requires a lot of effort. However, it does avoid sub-layer lock-in (no new programming languages, stacks, etc.) since some of these components use industry standard sub-layers. http://www.saasshowplace.com/ has an enablement category with some examples. As an aside, the platform we are working on alleviates many of the issues discussed, so the best alternative is yet to come;-) Hi Arun,

Thanks for commenting. Currently, the only viable alternative is to piece together custom code with various SaaS components available by providers. The problem is, this still requires a lot of effort. However, it does avoid sub-layer lock-in (no new programming languages, stacks, etc.) since some of these components use industry standard sub-layers. http://www.saasshowplace.com/ has an enablement category with some examples.

As an aside, the platform we are working on alleviates many of the issues discussed, so the best alternative is yet to come;-)

]]> By: Arun PC http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-746 Arun PC Mon, 22 Jan 2007 07:53:03 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-746 We know that the lockin is bad for everyone(of course not the owner of the platform) and we also know that we dont need a YAPL. Is there any other platform which doesnt pose this threat? Are there atleast lesser evils? Thanks, Arun.PC We know that the lockin is bad for everyone(of course not the owner of the platform) and we also know that we dont need a YAPL. Is there any other platform which doesnt pose this threat? Are there atleast lesser evils?

Thanks,
Arun.PC

]]> By: SaaS Blogs » Blog Archive » SaaSBlogs.com: Most Popular Articles of 2006 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-490 SaaS Blogs » Blog Archive » SaaSBlogs.com: Most Popular Articles of 2006 Thu, 04 Jan 2007 18:57:10 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-490 [...] Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand [...] […] Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand […]

]]> By: SaaS Blogs - » Marc Benioff, Please Stop Confusing Me http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-39 SaaS Blogs - » Marc Benioff, Please Stop Confusing Me Wed, 15 Nov 2006 23:08:18 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-39 [...] Salesforce.com has definitely reached powerhouse status, and is one of the main proponents of SaaS. For this, I thank them and really see them as a driving force. That aside, what is going on in Marc Benioff’s head? I wrote an article a while back about Salesforce.com using Apex as a lock-in strategy, which spilled over into a ZDNet blog article, and was vehemently opposed by Salesforce.com employees in both articles comments, with arguments ranging from there is no lock-in to there is no way around lock-in and expecting application portability is unreasonable. [...] […] Salesforce.com has definitely reached powerhouse status, and is one of the main proponents of SaaS. For this, I thank them and really see them as a driving force. That aside, what is going on in Marc Benioff’s head? I wrote an article a while back about Salesforce.com using Apex as a lock-in strategy, which spilled over into a ZDNet blog article, and was vehemently opposed by Salesforce.com employees in both articles comments, with arguments ranging from there is no lock-in to there is no way around lock-in and expecting application portability is unreasonable. […]

]]> By: SaaS Blogs - » Vendor Lock-in: Not new. Not gone, no matter what they say. http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-25 SaaS Blogs - » Vendor Lock-in: Not new. Not gone, no matter what they say. Thu, 26 Oct 2006 20:32:00 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-25 [...] We’ve had our fair share of vendor lock-in (handcuff) discussions on this blog.  [...] […] We’ve had our fair share of vendor lock-in (handcuff) discussions on this blog.  […]

]]> By: Tim Anderson’s ITWriting - Tech writing blog » Salesforce.com, Apex and Web 2.0 vendor lock-in http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-23 Tim Anderson’s ITWriting - Tech writing blog » Salesforce.com, Apex and Web 2.0 vendor lock-in Mon, 16 Oct 2006 12:09:53 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-23 [...] Salesforce.com, Apex and Web 2.0 vendor lock-in By Tim There’s a debate under way about whether the new Apex language from Salesforce.com represents a vendor lock-in. Sinclair Schuller says it does; David Berlind says mostly not. Berlind argues that the lock-in is mitigated since you are not forced to use Apex, but can use the same functionality via SOAP web services. I recently wrote a comment on the same topic for IT Week. [...] […] Salesforce.com, Apex and Web 2.0 vendor lock-in By Tim There’s a debate under way about whether the new Apex language from Salesforce.com represents a vendor lock-in. Sinclair Schuller says it does; David Berlind says mostly not. Berlind argues that the lock-in is mitigated since you are not forced to use Apex, but can use the same functionality via SOAP web services. I recently wrote a comment on the same topic for IT Week. […]

]]> By: Roman Rytov http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-21 Roman Rytov Sat, 14 Oct 2006 06:07:13 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-21 I think SF's targeting two things: more complex applications and eventually in-house deployement for big companies. More here:http://roman-rytov.typepad.com/miles/2006/10/whatwho_salesfo.html I think SF’s targeting two things: more complex applications and eventually in-house deployement for big companies. More here:http://roman-rytov.typepad.com/miles/2006/10/whatwho_salesfo.html

]]> By: SaaS Blogs - » Going From Software Developer to SaaS Developer Without Giving Up The Ghost http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-19 SaaS Blogs - » Going From Software Developer to SaaS Developer Without Giving Up The Ghost Fri, 13 Oct 2006 18:42:33 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-19 [...] To tie it all together let’s assume that none of the three previous issues have deterred you and you’re ready to jump head first into the SaaS waters.  Not so fast.  What happens if you fail?  More importantly, what happens if your approach leaves you no option but to give up the ghost?  Well, going for broke and developing a standalone solution (application with SaaS tenets rolled into it) is perhaps the riskiest bet - and leaves you with essentially no room for error because as soon as it doesn’t work your bottom line dips.  Not to mention the enormous outlays in infrastructure and development costs.  So perhaps you turn to enablement platforms - they’ll take care of the SaaS for you and you keep just doing what your doing.  Again, not so fast.  As Sinclair popularly pointed out, current platforms introduce vendor lock-in that leaves you feeling a bit used (and broke, and without reusable code) should something go wrong. [...] […] To tie it all together let’s assume that none of the three previous issues have deterred you and you’re ready to jump head first into the SaaS waters.  Not so fast.  What happens if you fail?  More importantly, what happens if your approach leaves you no option but to give up the ghost?  Well, going for broke and developing a standalone solution (application with SaaS tenets rolled into it) is perhaps the riskiest bet - and leaves you with essentially no room for error because as soon as it doesn’t work your bottom line dips.  Not to mention the enormous outlays in infrastructure and development costs.  So perhaps you turn to enablement platforms - they’ll take care of the SaaS for you and you keep just doing what your doing.  Again, not so fast.  As Sinclair popularly pointed out, current platforms introduce vendor lock-in that leaves you feeling a bit used (and broke, and without reusable code) should something go wrong. […]

]]>