The Emerging B2B Market

It seems like everyone is getting into the online gambling B2B space at the moment - it feels like every couple of months another operator brings a white label or a feed to the market. This is a trend which has repeated itself many times before in other industries, and web's unique properties as an integration medium between organizations simply accelerates the process.

Over the next few years the gaming industry is going to polarise into marketing-led organisations which own the customer, and technically-led organizations which own the product. This type of supply chain specialization isn't new to most of us and, excluding a few exceptions that might manage to keep a foot in each camp, we'll all need to choose whether we gather around the data and the platform or the customer and the presentation.

History teaches us that, as this unfolds, the waters will be muddy for a while. When operators analyze their portfolios most will find that they have something which can be leveraged into this new B2B market as well as aspects of their business which they are better underpinning with someone else's product from that same marketplace. Add a conservative view on risk and the relatively low level of efficiency that is a property of any newish market and, for the foreseeable future anyway, most organizations will be keeping hold of capabilities which overlap with (and perhaps even have a poorly defined relationship with) external products integrated into the enterprise.

The trick to making sense of this is in the meantime is going to be clearly defined boundaries. We have many good consumers (we all know how to run a book or some games) and few good producers (not many of us have worked out how to take something highly personalized for us and package it up generically) and B2B operators are going to have to take the lead by clearly setting out the scope of their services, how they can be easily integrated, and - perhaps most importantly - what bookmakers are able to do with those services.

At Sporting Solutions we don't sell feeds or access to databases of sports content - those things are just delivery mechanisms - what we sell is automation, cost effective product expansion, and cost reduction tools. The important distinction here is defining our product relative to it's use in an operators environment. After all - we can hardly claim that we offer more cost effective solutions to the sports gambling industry if, for example, an operator has to take our feed and still keep a large contingent of manual data entry or content management staff busy.

Devops design patterns

If you are a developer of a certain age (i.e. old like Dan and I) you would have lived through the "Gang of Four" Design Patterns era in the mid '90s. When the GoF book first came out in 1995 it had a spectacular impact on the development community - it was up there with "The Internet for Dummies" in terms of the best read tech book. You couldn't move with out hitting a design pattern. They were everywhere. They were in requirement specs, architecture specs, job specs and even in people's code.

It was usually an ominous sign when you saw them in code because you could be pretty sure that you would find all the patterns, everywhere - a clear indication of buzzword bingo being played by a development team that wanted to make sure their CV was chock full of the latest Abstract Builders, Observers, Memento's, Flyweights and everyone's favourite: the Singleton. (Never has so much damage been done by one pattern as the Singleton!)

As with all meme's the design pattern concept has started to drop out of favour in recent years, which is a shame as Patterns are actually a very powerful metaphor for describing systems.

The originator of the design pattern concept was Christopher Alexander. He was an architect who was interested in creating a pattern language that would help people to build houses and communities of any scale. Design patterns in the technology community have largely been restricted to developers and it is rare to find systematic use of patterns to describe other areas of engineering life. At the risk of getting shouted at by Doug, I have never, for example, heard of SysAdmin Design Patterns. Why is that?

I was therefore interested when I found a post this morning on a devops blog about design patterns for operations teams. The blog is really little more than a teaser but it got me wondering whether having a "pattern language" to describe a whole range of engineering tasks, not just development code structures might be useful. Would it be useful to have patterns describing various deployment options or ways/means to monitor systems? Would a set of operational pattern languages help us in describing the tradeoffs between various failure handling scenarios? Would it help us to cross boundaries between development, platform and ops? Would being able to express things as a pattern help people from different teams to think about what they really need to get done and why?

Thoughts?