Integration Consultants

Through Sporting Solutions, our B2B subsidiary, we provide a product that we believe is of significant value to our partners. But of course we'd say that, right? We also believe - as did Drucker - that value is not what you put into your product, it is what your customer takes out of it. Therefore we appreciate that how valuable our product actually is to any given partner is entirely down to how they use it.

Data from our API could be put to so many uses - from making a fairly simple ticker application which scrolls upcoming sports events across an operational screen through to automating the complete bookmaking lifecycle; setting up events, updating website content, pricing and probabilities in real time, and resulting after events. Obviously my examples here represent two opposite ends of the value continuum from a customers perspective - same feed, same data, very different business returns.

With that in mind, we're introducing a new role into our organization - integration consultant - with a presales and postsales remit to help our customers get maximum value out of our product by analysing their existing systems, planning their use of our feeds, and seeing their integration project through, all side-by-side with their own engineers. Free of charge, anytime you need it.

We want our customers to love our product and to stick with it, and helping them to get the most out of it seems a lot like a shortcut to that to me. Another first in the online gambling world I believe.

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?

Expressing Non-Functional Requirements

NFRs have recently been a topic of debate in our hallowed halls and, as usually happens in most good technical teams, there isn't any shortage of ideas, good patterns, and approaches to quality - just a lingering feeling that life would somehow be better if we had a more consistent and explicit definition of done.

A few years ago I wrote a short series on what I called The 6 Principles of Webscale Computing and, now that I revisit them older and [depending on whom you ask] wiser, I can see a little room for a bit of a brush up. Those key elements which I hold most dear are:

1 - Scalability
2 - Maintainability
3 - Quality
4 - Security
5 - Availability
6 - Usability

What I found particularly effective was documenting NFRs as user stories; this let us express them in a format that developers are already familiar with and make them a bit more specific and actionable than just 'do a good job'. Using the as-proven-by story clauses allowed that extra degree of flexibility which good engineers will use to make interpretations appropriate to the project they're working on - deftly sidestepping the joint pitfalls of waste (gold plating little used or less critical components) and undercooking (not putting enough in where it counts most). And, after all, a non-functional requirement is still just a requirement and if you want something done in software development there is no better way than to 'require' it.

Over the coming few weeks I'll be dusting those old stories off, giving them a bit of a polish, putting them back up here and - to strike terror into the hearts of my team - turning up to their demos to see them implemented in practice!

Where are the brown M&Ms?

If a picture is worth a thousand words, what value would you put on a bowl of M&Ms?

An article in this month's Fast Company tells us about how Van Halen used to have a clause, buried deep in the contracts with concert venues, that stipulated that the venue would forfeit all costs if there were _ANY_ brown M&Ms backstage. At the time many people thought that clause 126 was simply the ultimate example of rock excess. In reality it was there for a very specific purpose.

The contracts were very, very, very detailed and a successful concert meant that everything had to be in place and working. The M&M clause was a simple, visual feedback indicator that showed whether the organiser had actually read, and fulfilled, the contract. If there were brown M&Ms backstage then that would be a tell tale sign that a venue had not fully read the contract. The group would make sure that a thorough examination of the venue was carried out. Invariably they would find a major problem that could have derailed the concert.

You don't always need thick, verbose, progress reports to know if things are on track. Often, all you really need, is a simple, visual indicator of potential trouble.