August 19, 2018 · API SDP

SDP is dead, long live APIs!

The SDP platform has been a personal journey for me, as I started my career in telco implementing it, over the years I have seen it go through its paces, and now 10 years later, I am migrating services off it to an API platform.

In the beginning...

There are many industry verticals - telco, banking, mining - that has their own characteristics and contraints that make them unique. They each had their own terminology that defined them, even though they all served customers, but their processes and systems always catered for the structures each vertical. Banking has accounts and cards, telco has the triplets - MSISDN, IMSI and IMEI, that drove how systems were built, and the key data that always needed to be catered for.
In telecoms companies, they had this huge radio and core network that made the bulk of the revenue, and they reached a point where they wanted to start building other services on that of that network. Services based on Messaging (SMS, MMS, USSD, IM), location-based services (using that huge radio network to offer unique services based on the location of the subscriber/customer, SIP and other voice services, presence, convergence - Fixed Mobile Convergence (FMC), data and video (IPTV), and a whole bunch of other Value Added Services (VAS).
So in order to develop these services, Telco's needed IT systems that allowed them to use the vast amount of data embedded in the mobile network that allowed them to develop, deliver, and bill for these services. Normal off the shelf (COTS) IT systems, like standard ESBs, portals, CRMs, etc, needed to understand how to idenetify a mobile customer (MSISDN), and how to speak the different protocols needed for each system (SMS, USSD, etc). Many VAS services started off like this, perhaps early 2000s, and heavy developement and customisation was needed for these COTS systems to undestand telco-specific nuances. And thats how an SDP was born: a Service Delivery Platform, that allowed Telcos to develop and deliver and service over a mobile network. It came with pre-configured drivers and integrations into the Messaging and other platforms, and allowed services to be mashed-up to form different higher levels of services. This allowed telcos to quickly design new services, with-out much developement, and respond to market needs. But telcos knew they could not think up and design all conceivable services, so they needed a way to expose mobile functionality to external companies, for them to offer new and unique services. So the SDP was the main conduit for external companies to integrate into the telcos, reach the mobile customers, and build new services. The SDP allowed the mobile network capabilites to be exposed externally to the telco, and allow other VAS and WASP operators to build their own services using mobile network functionality. This spawned the millions of services we have today, where customers can use their mobile phone to pay for services using their airtime or mobile accounts, and consume services that involve SMS and USSD and a host of other mobile services.

I started off at a mobile operator just over 10 years ago, working on our first SDP implementation. I used to integrate into a location based system (LBS), and exposed it using Web Services to 3rd parties, allowing external companies to locate subscribers, get their consent, and bill for the whole service.
A few years later, we developed another SDP, and now 10 years later, I am responsible for my 3rd SDP - this time a global platform serving 300 million customers in 22 markets across Africa and the Middle East.

What is an SDP?

There are many defintions of an SDP (this is a particularly very good background and definition of SDP). (btw, I love Alan Quayle's writings). The TM Forum defined a Service Delivery Framework (SDF), to define and agree on common design patterns. Microsoft had a solution as well.

SDP-overview

The main and common components of the SDP besides the run time, portal, etc are two things:

  1. Service Creation Environment - where services are developed and faciliates the rapid creation of services. I suppose considering the time period that SDPs were prevalent, during the mid 2000s, there was a big link to Java, and so many SDP standards and platforms where based on Java, like JAIN SLEE
    The SCE also exposes the services to 3rd parties, predominantly using SOAP, and famously Parlay X - a set of Web Services for Telecoms, now replaced by the GSMAs OneAPI - a set of application programming interfaces (APIs) that exposes network capabilities over the Internet.
  2. Network Integration and Service Orchestration Layer - this layer, normally based of an ESB or similiar, allows connectiivity to the different network elements (SMS, etc), and strings various services together. Later on, there was a big drive to base this layer off the SOA architecture.

So...why is SDPs dead?

Right, now that we understand what an SDP is, and why we needed SDPs in the first place, what is reason for claiming that they are redundant. I think its a few things:

Alan Quayle again sums it up here, saying:

And thats the main point - we cant be Telcos any longer, we need to be part of the larger eco-system. This has been driven by the increased use of Open Source in all industries, and the convergence of standards for APIs and web technologies, which means that telcos can join the rest of the world. See T-Mobile's Un-carrier - where they dont want to be seen as a Carrier/Telco any longer.

Perhaps a cause, or a maybe a result of the above, is the convergence of industries. Banks are becoming more like telcos by implementing VoIP and other features (in my previous team we lost a bunch of telco engineers to a bank), and Telcos are the new Banks! with Orange and the likes hoping to capture the huge un-banked African continent.

A former senior and experienced banking guy joined our team, and after I explained our setup to him, which included the SDP, his inevtiable question, as he cocked his head was "Whats an SDP?". Telcos need to stop doing that.

So, where do we go from here?

If SDPs are dead, what replaces it? Again looking at T-Mobiles Uncarrier program, its about the digital transformation towards an API-first mindset. This is based off technologies like:

SDP-APIM

Coming back to point of the focus of the SDP being all about service creation, but forgetting about how to expose and consume those APIs. On the other hand, API Management Platforms are all about how to discover, register and consume those APIs, and about designing those APIs for their intended target - developers!. The product and focus is no longer on the building the service in the SDP, its moved a level up - the product is now the API.

I recently got pinged on LinkedIn from a developer of a JAIN SLEE based SDP - so it seems SDPs might still be alive-an-kicking. But their time is up, soon!

  • LinkedIn
  • Reddit
  • Google+
  • Pinterest
  • Pocket