Some of the best fiction I read (other than the political landscape in the US) is from vendors. To listen to vendors, you will come away with the idea that each is playing on a completely different planet using star wars technology to create technological isolation and transport customers to safety on far-flung company-owned planets around different solar systems. What is more astounding is the number of people who, without question, believe what their vendor says!
Vendors (especially in the DBMS space) are struggling to establish discernible, understandable, and meaningful advantages in the marketplace. That is how they become profitable - the goal of every vendor. The problem with all this is that these vendors are carrying significant technology baggage and customer support/continuity issues. Code that ran against a previous version of PYFP (Pick Your Favorite Product) must continue to run against the current version. I once heard a rumor (one that I find hard to believe, but it was quite widespread at the time) that a disk manufacturer had found a major "bug" in their firmware. This "bug", when fixed, would enhance the performance of that drive by 50%. But, the "bug", if fixed, would cause all the device drivers that were written against it to fail. Therefore, the company had to maintain the "bug". Of course, the smart thing to do was to re-release the product with a new name and not allow device drivers that supported the older drive to be supported on the newer drive (which the vendor was reported to have done!).
In many ways, all vendors are the same. They have to
- play the "open" game
- support the dominant standards (XML, SQL, Postal Service name and address formats, TCP/IP to name a few)
- provide some type of consistent performance, thereby making advances in their technology incremental
In other ways, the vendors are different. They are different in their
- technical implementations, optimizations and compromises (trade-offs)
- market presence
- war chest (the ability to invest in future technological advances)
- market strategy (other than taking the customers money!)
- the allies and alliances that they make
What does this mean to you? You need to ask questions and find out what a particular phrase means to your vendor, not just what it means to you. I was reading a vendor "new capabilities" statement one day and it was talking about its new functionality of parallel load. From my reading of their documents, I was confused about what they were doing. Later, when I was attending a data warehousing conference, I ran into a technical consultant from the vendor. I asked her what was meant by parallel load? Her response was that you could load multiple tables in parallel. I asked about parallel load on the same table, to which she replied, "Next release". Now, you see why I was confused. There was a common definition of what parallel load is, but they modified that definition to meet their marketing obligation.
Now, we can't blame this ALL on the vendors. We have to accept some of the blame ourselves. When I worked with the database group at Digital (it was sold to Oracle after I left), I saw requests for proposals (RFPs) from customers who defined the "must have" requirements of adhering to Codd's 12 Rules of Relational Database. The fact is performance would have been horrible if you had implemented some of those features and technology was not quite there so that those features would be useful. But we were able to "market" around those features. After we had won the proposal, the company was not interested at all in Codd's 12 Rules of Relational Database, but was extremely interested in getting the job done with good performance. Most of the "must haves" were never used. But vendors were excluded from winning if they did not have the "must haves". So we must understand that if potential customers are saying they "must have" features, then vendors must provide them. The other option is to go out of business. This option does not meet the goal of every vendor - to be profitable.
So, when searching for a vendor to provide a product to your organization, ask many questions. Even if you think you know the answer, you might be surprised. It is always better to be surprised before, rather than after, the purchase. Also, make sure that when you define what you "must have", that indeed, you "must have" it.
About the Author
Chuck Kelley is president and founder of Excellence In Data, Inc. and an internationally known expert in database technology. He has more than 20 years of experience in designing and implementing operational/production systems and data warehouses. Kelley has worked in some facet of the design and implementation phase of more than 35 data warehouses and data marts. He also teaches seminars, co-authored a book with W. H. Inmon on data warehousing and has been published in many trade magazines on database technology, data warehousing and enterprise data strategies. Please feel free to email him at chuckkelley@usa.net with comments (negative or positive) about this column or ideas for future columns.
For More Information
