First though, why was it an excellent event? Well, quite apart from the usual breadth of attendees and topics covered, there was a stronger consensus on what we should be doing and, as importantly, what we shouldn’t than we have seen for quite a while. SDPs have been around as a topic for a long time – in the early days, there was a lot of debate around what they were and what they were for. Today, things are much more focused and, while the concept is evolving, there’s a clear understanding of what we are trying to achieve with SDPs and where they are likely to go.

As we’ve noted before, an SDP is a framework around which service delivery can be organised and co-ordinated. It’s a flexible architecture that supports a range of services, via connectivity to resources and which enables service providers to control them and account for their usage. That’s not complicated but it does lend itself to a growing range of possibilities.

Perhaps the most intriguing idea that emerged from the event seems, at first sight, to be somewhat counter-intuitive. In the past, we’ve seen most of the focus on SDPs as a consolidated platform, removing silos and creating a more efficient locus for the launch of new services through access to resources and their reuse across multiple offers. However, a number of speakers voiced the thought that there should be several SDP platforms, each focused on a specific target group or market. In that sense, the SDP is becoming more of an API gateway, integrated into OSS / BSS systems, but federating access to resources within the network to service multiple applications and markets.

The idea was picked up by a number of analysts present and we made reference to it in our own presentation on enterprise and SME markets (coming soon to Slideshare). Simply put, there could be a consumer SDP, an enterprise SDP, an M2M SDP and so on – each of which would provide a platform for related services while using the same resources. Operators need to decide which vertical or horizontal markets are of interest and deploy the appropriate service platforms to support them.

This is a nice idea and one that can be supported by a fully-API enabled network. We’ve heard before how operators are recognising that API exposure from all network elements is not just desirable, but is now becoming mandatory. Those that are following through on such pronouncements are building a complete infrastructure of platforms with APIs that can then be connected into the SDP (or multiple SDPs) for service delivery and management.

There was, as usual, some discussion regarding APIs. Let’s state this once again: such discussions are a diversion. It doesn’t matter what API is exposed (so long as it conforms to generally accepted practice – e.g. RESTful). OneAPI and other standard initiatives may be laudable, but are generally too late to be of interest at this point. If they catch up, operators seemed open to the idea of using them, but meanwhile, many have gone ahead and implemented their own APIs.

Which brings us to the next and final point for this post. Who is the user of the APIs? Well, after years of nonsense about long tail and consumer-orientated application developers, it emerged that operators are building the APIs for two primary audiences. First, themselves – they want to use APIs to build better services, run their networks more efficiently and to provide common interfaces that are available to their internal teams. Secondly, they are choosing to offer APIs to partners that offer potentially higher returns. These can be larger enterprises or system integrators, or they may be upstream partners who can use assets owned by operators to enhance their own, OTT service offerings.

To summarise, here’s a quick checklist of the key points so far:

1. SDPs are API gateways and there may be specialist versions to support vertical or horizontal markets
2. APIs are mandatory, but standards matter less than flavour – REST is the accepted norm
3. Users of the API may be internal or external, but internal users are of huge importance
4. External partners need to represent high-value opportunities and the long-tail is irrelevant (to most)

There’s more to come soon, when we’ll look in detail at the process and cultural lessons from the conference, the role of marketing, and the attractiveness of the smart pipe.