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.

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:

• The SDPs primairy focus was on network abstraction and service creation. Its Service Creation module was all about connecting multiple network services together and creating mashups. However, not alot focus was put on how to expose those services, and especially, who to expose it to. The telco put all their energy into building the platform, and did'nt really think much about how it was going to be used. Kinda like the "build it and they will come" thinking, telcos used SDPs to expose their networks, but did'nt care who was the intended target? Was it developers, resellers...? This means that telcos treated everyone the same, did'nt care how the Web Service or API worked or looked, how developers discovered it, and how they signed up for it. It was very much an after thought!
• It was very telco specific. It meant that even if you just wanted your mobile resturant bookign app to send a confirmation SMS to subscribers, you (the developer) had to understand all the telco specific terminology, when all you really cared about was your app.

Alan Quayle again sums it up here, saying:

• "the broader scope of service innovation beyond the nebulous and to some extent discredited term SDP, so APIs, the broader concept of the services domain, the processes, partners, enterprise architecture, and relevant web-technologies could be discussed"
• “No longer being a telco person is good enough, we all need IT and web expertise to succeed in this converged world.”

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:

• API Management Platforms to replace the SDP service creation layer
• Microservices Platforms to replace the SDP Integration/Orchestration layer

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!