Why vendor lock-in is not always bad

Data Warehouse Automation Guide > DWA Guide  > Why vendor lock-in is not always bad

Why vendor lock-in is not always bad

For a long time I thought vendor lock-in was a bad thing.
And still it can be. But my point of view has become a bit more subtle. Let me explain.
Vendor lock-in, what is it? On Wikipedia you can read:
“In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.”

I could not have said it better.
Also when using Data Warehouse Automation tools, vendor lock-in is almost inevitable. There are even two different vendor lock-ins related to Data Warehouse Automation:

  1. Dependency on a tool you are using.
  2. Dependency on consultancy of a firm that has implemented your data warehouse.

I will explain them both in more detail.

Dependency on a tool you are using

I think this is not necessarily a bad thing. It depends on the circumstances.

When should you worry about tool lock-in:

  • When the tool is a one man project, that is not commercially sold. You are not only locked in the tool, but also in the vendor, and you can have question marks about future support, development and availability of the tool. In this situation at least the tool should generate native code, so your data warehouse can still be maintained manually, even if the tool is not available anymore. But still this is not an ideal situation.
  • When the “home-brewed” tool is used by a consultancy firm but is not commercially available. This creates a double dependency: on the consultancy firm and on the tool. You need to make good long term appointments to make this work.
  • When the tool is commercially sold but
    • (a) has a small user base (meaning the vendor has less income from licenses and therefore less resources to do new development), and/or
    • (b) there is a key man risk for development and support of the tool, and/or
    • (c) there is a dependency on the tool for daily operations (a runtime component) and a subscription license model that cannot be paused when there are no new developments of the data warehouse, unless it is so reasonably priced that you do not care.

When is tool lock-in not a bad thing (all arguments must be applicable):

  • When there is no risk of discontinued support and development of the tool in the future.
  • When the license does not have to be upgraded for every version, or at least the costs can be paused when the tool is not used for new development (unless it is so reasonably priced that you do not care).
  • If the tool uses a runtime component, this component must be stable and able to manage and execute the operational processes needed to keep your data warehouse up and running.

When you are still locked in while you might not realize this:

  • If a tool is generating native code, you might think you are not locked in, but in a sense, you still are. Why? Because you have a meta data lock-in! The generated code (SQL, SSIS packages, or whatever) is not intended to be maintained manually. So if you stop using the tool (or are forced to do so), you might have to do manual maintenance, and all the advantages of data warehouse automation will be gone! Only when your data warehouse has reached a certain level of majority and has very little changes yet, you might consider manual maintenance of generated code, but in general I would say no to this.


Think well before getting locked-in ..
Picture credits: (c) Can Stock Photo / PhotoEuphoria

Dependency on consultancy of a firm that has implemented your data warehouse

If a consultancy firm is using it’s own data warehouse automation tool – that is not commercially sold – you might get involved in a consultancy firm lock-in. Maybe the tool is installed and your employees are also allowed to use it, but even then you should be aware of some possible disadvantages:

  • Tool support and maintenance one man risk – do you know how many people within the consultancy firm are actually maintaining the tool?
  • Availability of knowledge – if your employees leave the company, can you find other employees that know or can learn the tool, is it documented properly, is the learning curve acceptable?
  • License terms – what have you agreed on, and for what period?

Maybe the comparison I make next needs a little while to get into your brain.
Would you prefer a consultancy firm that would make a design to do it in a common format, say Microsoft Visio, ERWin, Power Designer, or in their own tool, given the fact that the project files could only be opened with their own tool, not to talk about possible instabilities of the tool? You want my opinion? I would prefer a common format, just to reduce the vendor lock-in.
Compare this with data warehouse automation. Would you prefer a consultancy form that would use their own data warehouse automation framework or tool, given the fact that it was not commercially available? Or would you prefer a firm that would use a commercially available tool, with a proven track record? So you could switch the consultancy without switching the tool when there would be a need to do so? You can guess my opinion.

(c) 2017 datawarehouseautomation.guide – Do not steal the contents – spread the link instead – thank you.

Hans Michiels
No Comments

Post a Comment

Comment
Name
Email
Website