It’s been interesting to watch the list of producers of live OData Services grow over the last few months.  The early adopters (like Netflix, some municipal & federal government agencies, and several Microsoft projects) have been joined by the likes of Facebook, eBay and twitpic.  The list is even gaining a sense of humour, as evidenced by the entry for Nerd Dinner:  “Nerd Dinner is a website that helps nerds to meet and talk, not surprisingly it has adopted OData.”  You can check out the complete list here:  http://www.odata.org/producers.

As of this writing, the list is up to 33 services with a good mix between large/high-profile entities with wide-ranging application possibilities and small initiatives often focused on just a slice of the tech community itself.  We need both, because it’s the big names with brand recognition that catch people’s attention, but small-scale tinkering by techies can be an excellent incubator from which new & creative ideas will eventually emerge.

OData, the technology, is “the web-based equivalent of ODBC, OLEDB, ADO.NET and JDBC” (Chris Sells, via MSDN).  Just as the ODBC specification and its descendants have enabled data access between clients and servers across widely disparate hardware and OS platforms, the OData specification promises data access between “consumers” (applications using standard web technologies) and “producers” (data sources residing on various web server platforms).

OData, looked at as a movement, is creating an open-ended environment with a whole new range of business decisions for companies to deal with.  At the simplest level, the questions for a company choosing to publish an OData service are similar to those you would consider for a web application:

  • Scope:  Will the data be accessible only via a corporate Intranet, or will it be available on the open Internet?
  • Authentication/Security:  Will a user have to login to access the data?  Will some portion of the data be available without logging in?  The Netflix example is a good one to consider here—their movie catalogue is available to the general public, but a user’s movie queue is restricted to authenticated users only.
  • Will the data be Read only or Read-write?
  • What subset of fields from the database will be exposed?
  • What range of data from the database will be exposed?

The big difference, of course, is that you’re not the one creating the application.  You may also create an OData consumer application in addition to the OData producer data source, but the key is that you’re not the only one doing so and there are potentially many applications consuming your data feed.  This moves you up to a higher level of business questioning:

  • How might our data potentially be combined with other data sources (either by us or by others) and what value does that potentially add for our customers?
  • What type of new business relationships are possible with other producers of OData feeds?
  • What is the value to our business of this data (i.e. do we need to charge for access to it)?

If your company makes a product that generates data in some form, adding an ODBC driver opens it up to a wide range of general-purpose reporting tools so your customers can slice & dice the data to their hearts’ content.  The benefits of providing data connectivity to the desktop are proven and clear.  If you’re already doing this, what are your company’s plans for providing data connectivity to the web?  Let us know, we’d love to hear from you.