Beyond SDPs

By TMCnet Special Guest
Grant F. Lenahan
  |  May 01, 2011

This article originally appeared in the May 2011 issue of NGN.

Years ago, The Economist famously defined a product (as opposed to a service) as “something that can be dropped on one’s foot.” We are in a similar definitional situation with one of the industry’s most important concepts – the service delivery platform.

Every supplier claims to have one. Every operator knows they need one, and most have a fairly good idea of what they think one is. Every industry pundit has an SDP architecture. I’m here to weigh in on what exactly an SDP should be and shouldn’t be, but most importantly, why. (Full disclosure: Telcordia markets service delivery solutions.) I’ll draw on much more than a vendor’s perspective in this task: I co-founded the TM Forum’s (News - Alert) team of Service Delivery Frameworks and chaired its SDP summit, so I’ve been down this road before.

SDPs have actually been with us for the better part of a decade. Their earliest appearance was in the mid-2000s as mobile operators needed add-on capability to vend software – ringtones, wallpaper, mobile pictures, and VAS messages. Legacy mobile OSS and BSS were not geared to these sorts of demand-based content, which had to be delivered in the right format for the right device, and might be part of a package. The SDP was born.

Since the original SDP’s claim to fame was the quick and flexible addition of new SKUs, the industry began labeling all sorts of related products as SDPs – products that performed more flexible auxiliary rating and charging; others that allowed (in principle) internal service creation via mash-up; and content management systems that were tailored to the unique attributes of content – digital rights, various formats and trans-codings, etc. All of these were in fact single products, often proprietary silos in fact, that you might be able to drop on your foot.

Somewhere in the last few years the industry made a major leap and began to think about SDPs architecturally – as a way to address fundamental change in our business. In my opinion, the major changes are:

·         The growing importance of content as a new revenue source: This extends from music to IPTV to web video to…anything.

·         The emerging importance of third-party value chains, since third parties not only own most content, but many offer innovative services: If they remain over the top, both telcos and consumers lose. Telcos lose financially and consumers lose from a QOE perspective.

·         To compete with the web giants (NetFlix, YouTube (News - Alert), Google, etc.), CSPs need to innovate more quickly, and to create services that cross technology silos. In effect, service creation can no longer remain within platforms – say, your app server or messaging server – they must become CSP (News - Alert) mash ups including charging, location, user interaction, etc.

·         The emergence of handset apps as a way to deliver services: CSPs need to find a way to insert themselves in the value chain, initiatives such as WAC (News - Alert) 3.0 with the inclusion of OneAPI can offer this essential linkage.

So those are the goals. Innovate quickly and cheaply. Create convergent services. Gain revenue in conjunction with third-party services. And enter the fray for digital content. Now, what’s the implication for SDPs, and what you should buy?

Einstein once said that things should be made as simple as possible, but no simpler. In that spirit, let’s cut to the chase. An SDP is a fundamental re-think of service creation.  The idea of telco service creation goes back to the intelligent network. At its best, service creation has enabled innovation – witness the hyper competition and innovation in places like Latin America and India, often leveraging flexible prepaid. At its worst, service creation was a fancy toy that no one really employed. Much of the “advanced” regions went down this route. But service creation always remained within platform silos. IN had service creation. Very likely, so does your IMS app server, and your VAS messaging gateway. Maybe you can script your location system to generate alerts or respond with info. However, by and large, traditional service creation has the following limitations:

·         It is not exposed efficiently to third-party use and innovation.

·         Platform-to-platform communication is still achieved by costly SI and bespoke calls.

·         Services are custom, and rarely re-used. Management support is completely bespoke; and traditionally has been one of the long poles in the tent.

A re-architected software innovation environment can overcome many of these limitations. Rather than generate bespoke apps, they can be composed from what are, in effect, objects (services). These can be exposed into a common composition environment that eliminates the need for bespoke SI. And a select set can be published to third parties – “the web” so that others can create end user services that take advantage of your network’s capabilities – and share new revenues with you. (That’s the goal, right?)

So an SDP is more of a framework, or an ecosystem, than a single product. It is also more than simply a composition environment or a web services exposure layer. It must meet the needs for real-time, fine-grained internal development, as well as the needs for coarser-grained, well- defined capabilities for public exposure. And finally, it should allow each of these objects to have associated management support (discovery, fulfillment, assurance, settlements). This last item, I’ll point out, is the focus on the TM Forum’s SDF initiative, now re-branded as the Software Enabled Systems Management Solution – not a pretty name, but one that’s surprisingly descriptive, and one that’s addressing the final frontier to efficient multi-party business models.

I encourage the industry to think about the SDP as a framework that can expand and evolve to streamline our business, make us more innovative, encourage the wealth of web developers to take advantage of our capabilities, and helps us transform our business – making change faster and cheaper – and leaving silos behind.


Grant F. Lenahan is vice president and strategist for service delivery solutions at Telcordia (News - Alert) Technologies (www.telcordia.com). 


TMCnet publishes expert commentary on various telecommunications, IT, call center, CRM and other technology-related topics. Are you an expert in one of these fields, and interested in having your perspective published on a site that gets several million unique visitors each month? Get in touch.

Edited by Stefania Viscusi