Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Is there a set of industry approved rules to avoid vendor lock-in?

I mean something one can show to a manager or other decision maker that is easy to understand and easily verifiable.

  • Are there any universally accepted set of rules, checklist or conditions that help detect and prevent vendor lock-in in an objective, measurable way?

  • Have any of you warned a manager about the risk of vendor lock-in during the initial stages of a project?

share|improve this question
    
vendor lock in isn't necessarily a "bad thing" –  Ryathal Oct 24 '12 at 17:10
2  
This is a surprising good question, that's relevant to a large group of developers. Often you don't know you have this problem until it's too late. –  joshin4colours Oct 24 '12 at 17:16
    
Doesn't this question need further clarification as to the particular area of concern that you want to avoid vendor lockin. Otherwise, the answers that anyone can give are common sense (ie. add nothing of value). –  Dunk Oct 24 '12 at 18:08
3  
@Ryathal Oct: How can a lock-in (restriction of options, future choices) not be bad? –  Giorgio Jun 28 '13 at 16:09
1  
@Giorgio because support contracts are more important in the business world than ability to change, once a system is working that fact part A can be swapped with part X is irrelevant because no one will do that until there is a gun held to their head. –  Ryathal Jun 28 '13 at 17:13

3 Answers 3

up vote 7 down vote accepted

In my work as a consultant I frequently warn clients about the risk of vendor lock-in. This is from bitter experience of being called in to turn around failing projects: if you don't think about this at the beginning, then it will probably cost you in the long term.

There is no "standard checklist" but here is a good checklist of the main things that I look for:

  • Open API: is the API that we will be using (i.e. building a dependency on) open in the sense that it can be freely implemented by competing vendors?
  • Standards compliance - does the product conform with relevant industry standards?
  • Presence of compatible alternatives - Is there actually another compatible product (either commercial or open source) that we could switch in with minimal changes?
  • Open source - is the vendor's code open source (i.e. under an OSI approved license)?
  • Platform independence - is the technology stack portable across different platforms?
  • Contractual flexibility - can we terminate or scale back the contract early without significant penalties?
  • Independent service provision - are there credible options to buy services from different vendors (i.e. not just the original vendor)
  • Capabilities and skills - if we were to part company with the original vendor, do we have the required capabilities and skills to continue working effectively either in-house or with another vendor?
  • Record of good behaviour - does the vendor have a good track record that suggests you can trust them not to exploit any lock-in they may obtain?
  • Stability of requirements - are our requirements well defined and likely to stay the same? (if so, you can contract for these requirements up front and vendor lock-in doesn't matter so much...)

If the answer is yes to most or all of these questions, you can be reasonably certain of avoiding vendor lock-in. If not, you should be careful.

share|improve this answer

These are some guidelines I use when evaluating lock in:

Does the vendor use industry standard formats?

If you end up with tons of files and code that has to speak a foreign language, then switching is exceedingly difficult. If you have standard formats like XML and JSON not so. For instance ASP .Net uses aspx, which is markup that is neither html, nor is it valid XML. This makes it very difficult to convert those files or parse them.

Does the vendor supply sufficient points to integrate with their system?

Can you liberate your data out of the system, and integrate it with your own systems sufficiently via some form of interoperation, like web services? If you want to integrate it with your systems do you need to add more vendor products at a premium?

How hard is it to change out the solution for another one?

A constant sanity check is needed to see how difficult it would be to move away from the vendor. If the vendor's stuff pervades your entire infrastructure you should be weary.

share|improve this answer
3  
Another non-technical aspect is: what's the vendors track record with regards to responding to lock-in-related requests. Some vendors are better at it than others. –  Joachim Sauer Oct 24 '12 at 6:56

In short, i would look for reviews and feedback about vendor and the product.

Technically speaking, vendor locking happens when project has tight coupling to the vendor(the third party product).

How to avoid that ? By having alternatives and researching one question about each alternative - How hard is it to change out the solution for another one?

In addition to technical details of product that vendor promoting, it is very important to know the track of success/failure that other customers had with this vendor. It might look hard thing (Goggling, reading reviews, identifying how genuine is the review, etc..) to accomplish. However, there is credible rating system in US called BBB (Better business Bureau).

The records of US based companies in this independent Bureau are very useful and in 95% do reflect the reality. Thus, i will strongly advice to check with them as well.

share|improve this answer
4  
I'm hesitant to down vote this as it's not "wrong", but your answer doesn't really address the question. Vendor lock-in has nothing to do with the BBB. –  GlenH7 Oct 24 '12 at 14:28
    
Clarified the missing part of technical detail. –  Yusubov Oct 24 '12 at 16:13
1  
Good edit - it more directly addresses the question now –  GlenH7 Oct 24 '12 at 16:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.