I often get asked by people as to why you would want to build an ODBC Driver. Usually the people asking work for ISVs (Independent Software Vendors) that have their own database and/or reporting application.
I usually provide the following example.
Consider an ISV that sells into the financial services sector and has been making great progress licensing its proprietary database and reporting application. The ISV’s database is high performing and very scalable. Likewise, it has a great reporting tool that allows the customer to do some fancy analytics on the data in the database. Overall, the product’s code is well-developed and high quality. Everything is very modular, and everything looks good.
However, the ISV’s CEO is reviewing business and finds that the company is making largely departmental sales and that most customers only have 5-10 users of its great system. The CEO asks one of the company’s best customers – a major bank – why it is not deploying the product further than the 10 users it has. The customer says that it loves the system, but its other departments that could use the system want to connect to it using Microsoft Excel and Business Objects Crystal Reports. The problem is that data needs to be extracted from the system and then fed into Excel and Crystal through flat files.
This data connectivity problem is exactly what an ODBC Driver solves. An ISV might have a great system, yet unless standard business query, reporting and analytical applications like Excel and Crystal can connect, the system will always only serve a niche role with data stored in the system that is trapped in a silo.
Quite simply, an ODBC Driver allows a wide variety of applications to connect to a database through a standard interface and exposes the data to the maximum number of products and users.