This article originally appeared on the BeyeNETWORK.
If ever there was a two-edge sword, it would be vendor influence on an account. On the one hand, relying on the vendor for advice can be very beneficial. For example,
In a couple of words, because your vendor works with other organizations and experiences different approaches, he or she can provide a wealth of information.
Therefore, asking your vendor what their experience has been can be quite useful. And, practically everyone does it. (As a point of clarification, we are not talking about asking your vendor about detailed, sensitive competitive information. Ethically, your vendor should not be sharing that kind of information. But there is a wealth of general information that the vendor has that does not compromise its obligation to any single customer.)
And the vendor has more than just general industry information to share. Inevitably, the vendor has specific information about the product that you have purchased that is useful in its implementation and usage. How is the product best installed? What should the user expect? How should the user get started? On an ongoing basis, what should be done to the product to make it perform at peak efficiency? Etc. Nobody knows a vendor’s product as well as the vendor does, so it is natural to listen to the vendor for product advice. To do anything else would be foolish.
But there is a line—a very fine line—when it comes to taking vendor advice because it is possible for a vendor to give advice that is not in the best interest of the customer. Instead, it is in the best interest of the vendor. Often, this is a grey area.
Take the subject of mixing data marts and data warehouses within the same environment, for example. Suppose the vendor advises, “You should build all data marts in the same technology as the data warehouse.” In this case the vendor’s technology may be hardware or DBMS software or both. What is the effect of directing clients to build data marts in the same place as a data warehouse? Whose best interests are being served?
Consider this. In at least a crude form, a data mart can be built in any standard data warehouse DBMS—DB2, SQL server, Sybase, Oracle, Teradata, etc. If standard DBMS technology can be used to build a data warehouse, then it certainly can be used to support a data mart.
What happens when you build a data mart in the same technology and on the same hardware as a data warehouse? You would use up more capacity. Furthermore, the capacity that you use is the most expensive capacity that money can buy. Whose purpose does that serve? Not yours. It serves the purpose of the vendor, because now the vendor is charging you more and selling you more.
What happens when you decide to not listen to the vendor and place the data mart on a separate processor? For example, you call Dell and you find that you can buy a processor for your data mart at a fraction of the price the data warehouse vendor is charging. You find that software on a smaller processor is less expensive. You find that detaching your data mart from the data warehouse allows you to customize the environment as you wish. You find that other processing has no impact when you have your own data mart. You find that having your own data mart is really appealing for many reasons.
But most importantly, you find that you have control over your own processing and your own data. For a variety of reasons that makes a great deal of sense.
Now, once you have moved your data mart to another machine, your capacity on your data warehouse stretches further. Now you don’t have to upgrade to a new machine or add disk storage nearly as fast. You pay your vendor less money. That makes you and your organization “happy campers.” At whose expense? The vendor’s, who should never have told you to build the data mart on the data warehouse in the first place.
And there are other issues, such as should you build an ODS? Or, should you try to turn your data warehouse into a real-time transaction processor? Should you put summary and detailed data in a data warehouse or just detailed data? Should you update in a data warehouse? There are a thousand architectural issues that can be addressed.
There is a fine line to be walked by the vendor when it comes to giving advice. At the end of the day, you are responsible for your organization and its resources. Simply opening up your wallet and asking the vendor not to take too much is an irresponsible way to handle that responsibility. Vendors just don’t have the will power that they ought to have.
Bill is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations. Bill can be reached at 303-681-6772.
Editor's Note: More articles, resources and events are available in Bill's BeyeNETWORK Expert Channel. Be sure to visit today!