Vendor lock-in. Even if you’ve never heard the expression before, you’ve probably experienced this unfortunate — and slightly shady — approach to business.
And if you’re trying to build the best data stack for your business — choosing the best solutions for your unique use cases — vendor lock-in can stand in your way by severely limiting your options.
What is vendor lock-in?
Do you own an iPhone? How about an Apple TV? How about an iPad? All great products, no doubt. And the ease with which Apple products interact with other Apple products is unsurpassed.
But have you tried to share media files on your iPhone with a PC? Have you tried to sync your iPad with a Garmin smartwatch? Not quite so easy. In fact, often tricky, buggy, and prone to annoying issues.
This is a perfect and well-known example of vendor lock-in.
If you’re looking for a definition, Wikipedia has a good one:
In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products, unable to use another vendor without substantial switching costs.
The use of open standards and alternative options makes systems tolerant of change, so that decisions can be postponed until more information is available or unforeseen events are addressed. Vendor lock-in does the opposite: it makes it difficult to move from one solution to another.
Vendor lock-in also plagues the modern data stack
To be sure, every business wants as much of your business as you can get. And this includes SaaS companies like data.world. We want our product to be “sticky,” and we want you to use it.
But not at the expense of your ability to choose or your freedom to build whatever data stack works best for your company. In short, we want to help our customers avoid vendor lock-in.
And you should feel the same way. Even if you think you’ll be happily locked into a suite of tools that currently meets your needs, your use cases will certainly change and evolve over time, and you’ll be forced to change and update your tools to support them.
Your infrastructure is going to change both more slowly and more quickly than you expect. Those legacy tools and systems you plan to deprecate? Even though you can strategically move a lot to your modern data stack, it’s not going to happen as fast as you’d like. And at the same time, you’re going to be constantly adding new, more-advanced BI tools and new data.
With all that in mind, whatever you’re using to underpin your data infrastructure has to be infinitely flexible and able to work with whatever tools and systems you’re running. If not, you’ll be constantly disassembling and rebuilding your data stack. Or worse: you’ll be constantly buying an entirely new stack whenever your current stack’s limitations become too much to overcome.
data.world’s knowledge-graph-based data catalog is the cure for vendor lock-in
How can you select a data catalog that prevents vendor lock-in? By choosing one built on an infinitely flexible, infinitely extensible knowledge graph, which empowers you to connect to any type of data or data tool with a minimum amount of work. And that’s data.world.
The proof is in the pudding: we work with numerous revered enterprise customers who not only use less-than-common data stacks, some of their systems are home-grown and entirely unique to their business. Those proprietary, self-built systems are sometimes the most important parts of their systems. And we can work with them all.
Granted, no data catalog could possibly include an out-of-the-box connector that collects metadata from a homegrown system, including data.world. (Unless that system was speaking some kind of published standard, which is almost never the case.)
But unlike the competition, our models fit into a framework that is completely open ended. So If you want to model a standard tech differently that what we provide out of the box, you can. And if you want to represent something in your catalog that we don’t have a standard for, adding that model is easy.
Our knowledge-graph-based catalog empowers you to choose whatever tools you want within your stack, and catalog any and all data in your ecosystem.
It’s your data. Do with it what you want.
Beyond being locked in to a limited set of tools, some data catalogs lock down your data itself, only letting you access it and use it for purposes within the catalog itself.
But if your data catalog is simply an application for people to click around in, only exploring the catalog interface, you’re incredibly limited in what you can do with your data.
Your data catalog itself should be a data asset; it represents all your organization’s collective knowledge, and you should be able to take that data and use it to power other applications and use cases outside of the limitations of the catalog itself. And if you decide to stop working with a particular vendor and using their interface — including us — you should be able to easily take your data somewhere else.
When it comes to your data stack, refuse vendor lock-in
When it comes to the tools you choose to build your data stack, you should select them based on which are actually the best, and not based on which you’re forced to adopt because they alone integrate with your current stack. And nobody should be able to decide what you get to do with your data but you.