Vendor Lock-in: Not new. Not gone, no matter what they say.
We’ve had our fair share of vendor lock-in (handcuff)Â discussions on this blog.Â
Vendor lock-in issues do in fact exist in SaaS platforms, and although platform providers might use a little smoke and mirrors to avert your attention from the handcuffs that exist, you should be aware that utilizing a proprietary platform means that it comes with some of the traditional enterprise vendor lock-in issues. Lock-in hasn’t been avoided. Not yet.
Phil Wainewright clearly and concisely illustrates that new SaaS platforms like Apex and now NetSuite take an approach that appears SaaS-rific on the surface but does, in the end, introduce our old friend vendor lock-in.
No Software! But more programming languages … – ZDNet
Related Posts
Tags
Share This
How do you avoid vendor lock-in. Phil seems to be saying that SaaS vendors are avoiding the problems of the on-premise vendors by making all the customizations work through upgrades, not much more.
How would you make a system do what you want but be able to port all the metadata and data over to another system without work?
Unless there was some data definition standard linked to a workflow, business logic, alerting, reporting, dashboarding, custom client-side and data integration “standard” that let you package all those things up and take your app to another vendor, isn’t every system just locking you in?
Well, I’m not so sure it can be done without *any* work. Granted, all systems create some level of work when it comes to moving an app to another vendor. The question, I believe, is whether or not it is portable enough to allow such a thing to even happen without a rewrite of that app. Portability is a consequence of implementation choice, which in turn will be dictated by vendor platforms. If a vendor makes Super Duper Platform such that any implementation of an app on that platform is bound to the semantics of the platform, then you are at the high end of “lock-in.”
Please note that when I say “app” I am not referring to an app that extends and/or works with some “core application” that provides a “platform” ala a hub and spoke system. Instead, I am referring to an independent, self contained application, and any loose couplings it has to external entities applications. I whole-heartedly agree that in the scenario where an app is in-fact an extension of the functionality exerted against Salesforce data schema, and written in something in Apex, it would be absurd to port it to say, NetSuite or SugarCRM. But that’s not what I classify an ‘app’, or at least not in the traditional sense.
Sinclair
I think you hit it right on the nail. Far too many times I have seen people argue that you can’t just port your application from SalesForce to SugarCRM and I couldn’t agree more with them (Great discussion here: http://blogs.zdnet.com/BTL/?p=3774 ). But I don’t consider those a true application or a true platform for that matter, if anything, they are extensions to the application and Apex is a glorified tool to write SalesForce extensions.
I don’t consider a platform something that forces me to be tied to another application’s schema like in the example of SalesForce. What happens if I don’t want a dashboard or their tabs or any of the common components that SalesForce uses? I think its great that they offer the components as an option to anyone that wishes to use them and at that point they would be making a conscious decision of locking themselves in to SalesForce but there should also be the ability to opt NOT to use the components and use my own.
So if instead SalesForce allowed you to write an application in a common language (Java or any .NET language widely accepted) where they worry about scalability, subscription services, single sign on, etc… then I would say that they have mastered a platform truly worthy of calling themselves a platform.
In the meantime I can’t wait to see where the competitive world of a SaaS platform will take us and I have a feeling that the first one to get it right will be around for a long time.
Abraham, it’s just I wonder, if you wanted something close to a CRM system why would you take .Net and SQLServer and rebuild everything? Why not use SugarCRM or salesforce.com and build out? If you want an ERP, why not get Compeire or NetSuite and build out?
Hasn’t the definiton of “platform” been moving up for the last 20 years?
Before, it was the OS, and you could read and write to the screen and files. Early 2000s, .Net or J2EE get you a database layer, user management, horizontal scalability in a clister. Aren’t the packages with standardised extensions going to the next step? You can create your own schema in salesforce (I’ll pick an example I know), your own UI forms on that schema and custom business logic around it. It might not be ideal for a general leger, but many systems are run using forms, a database, and reports – why go back and write a form manager connected to a database? You’d use XForms, and then you already have some vendor lock-in. You’d use Reporting Services, or Crystal, or JasperSoft, and you’d have lock-in. Unless there was a meta-way to describe this and a meta-management system to take the meta-description and move it to another system, I don’t see how .Net, SQLServer, Reporting Services, MSMQ and all the other services makes it less locked in than using Apex or SuiteScript or PeopleTools or Fusion.
I think if you want a vendor that sells you a service where you program in .net and just have access to an RDBMS, there are many of those – hosting companies. But now, if you don’t want to start from scratch, there are new choices that give you an app or app-like components to start with.