Saturday, 20 March 2010

Why don't we have a common data format?

I've written before about the changes we're going through as an industry and the fact that we don't have a common data format - or even consistent terminology for describing things like events, games, markets, etc - is a constant barrier to exchanging information between organizations.

More operators are becoming both producers of their own B2B product and consumers of other operators B2B products and this is pushing up the need for interoperability. It's difficult enough during initial discussions to clarify what both parties mean by fixture (are we talking about a betting opportunity withing a game or the sporting match itself?) and - although it might seem like pedantry on the surface - these things matter when customers are trying to get a clear idea of what they're buying and what they're committing to in a contract.

And then, when we move on to implementation, the fun really begins. Because all our schemas are unique, closing that gap becomes an integration problem. Typically this is overcome with a mapping service or parsing raw data and inserting it directly into a target database. Whatever the approach it is usually a little time consuming and, due to the theoretically unlimited number of variations, requires a bit of ongoing manual intervention. There are only so many options for joining together dissimilar data structures.

Many other industries have been through this journey, and have established some common formats to make exchanging data easier. At Sporting Index we've taken SportsML - used by many news and content organizations as an open format for exchanging data about sports - and make some extensions to it to include e-gaming type information.

As a B2B operator in any industry you always want some standardization in this area - anything else is simply a barrier to the adoption of your product. Of course as an incumbent data provider proprietary protocols and schemas act as a barrier to your customers adopting someone else's product instead but, if you are confident in your product and you provide a good service, why would this be an issue for you?

0 comments:

Post a Comment